Date: Thu, 10 Oct 2002 22:13:37 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Craig Rodrigues <rodrigc@attbi.com> Cc: freebsd-standards@FreeBSD.ORG, <freebsd-hackers@FreeBSD.ORG> Subject: Re: Problem detecting POSIX symbolic constants Message-ID: <20021010213351.X8598-100000@gamplex.bde.org> In-Reply-To: <20021009222307.A9894@attbi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 9 Oct 2002, Craig Rodrigues wrote: > Earlier this year on the FreeBSD hackers mailing list: > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=278142+0+/usr/local/www/db/text/2002/freebsd-hackers/20020317.freebsd-hackers > > I was advised by Terry Lambert to use: > #ifdef _POSIX_REALTIME_SIGNALS > > to detect if sigqueue(), sigtimedwait, sigwaitinfo() were defined. > > I made this change to the FreeBSD configuration for ACE, a C++ > library used for systems programming ( http://www.cs.wustl.edu/~schmidt/ACE.html ). > > The change I made worked fine in -STABLE. > However, in -CURRENT, this test breaks, because _POSIX_REALTIME_SIGNALS > is defined, but it is -1. > > According to the letter of the law: > http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap02.html > > "The following symbolic constants shall either be undefined or defined > with a value other than -1." This law only covers 2 symbols (_POSIX_CHOWN_RESTRICTED and _POSIX_NO_TRUNC). _POSIX_REALTIME_SIGNALS is covered by more general and complicated laws. It may be undefined or defined to 0, -1 or 2001mumbleL. > So, this is legal way to implement these macros. It just breaks my code. :) > > Can I appeal to the freebsd-standards team to leave these macros undefined > instead of defining them to -1? #ifdef/#ifndef is a pretty common way > to detect if a feature is available on a system, especially when used > in conjunction with something like autoconf. No. If they were undefined (and _POSIX_VERSION is large enough), then their undefinedness means that applications must use sysconf() to determine if they work. Other cases are simpler: _POSIX_REALTIME_SIGNALS is defined to -1: This means that the interface is not supported. Applications shouldn't use it at either compile time, link time or runtime, since it might not exist in headers or libraries. _POSIX_REALTIME_SIGNALS is defined to 0: This means that the interface may work, and that it exists in headers and libraries, so applications may reference it in normal ways. It may fail at runtime; applications must use sysconf() to determine if it is actually _POSIX_REALTIME_SIGNALS is defined to 2001mumbleL: This means that the interface just works. sysconf() may be used to check that it works, but sysconf() must not fail. _POSIX_REALTIME_SIGNALS is undefined: Apparently the same as when it is defined to 0, except you cannot assume that anything related to it works until you call sysconf(), so you must not reference its interfaces statically, and must use a dll or something that references it. The dll is presumably available on systems that support it but not (except possibly a dummy version) on systems that don't support it. I think the case where the symbol is undefined should never be implemented in practice. It can be reduced to the case where the symbol is 0 using dynamic linkage with the complications for linkage not visible to the application. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021010213351.X8598-100000>