Date: Thu, 10 Oct 2002 01:49:15 -0400 (EDT) From: Garrett Wollman <wollman@lcs.mit.edu> To: Craig Rodrigues <rodrigc@attbi.com> Cc: freebsd-standards@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Problem detecting POSIX symbolic constants Message-ID: <200210100549.g9A5nFLn060516@khavrinen.lcs.mit.edu> In-Reply-To: <20021009222307.A9894@attbi.com> References: <20021009222307.A9894@attbi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Wed, 9 Oct 2002 22:23:07 -0400, Craig Rodrigues <rodrigc@attbi.com> said: > I was advised by Terry Lambert to use: > #ifdef _POSIX_REALTIME_SIGNALS Terry was wrong. If _POSIX_REALTIME_SIGNALS is undefined, it means one of two things: - The RTS option is not supported, or - You can't tell whether or not the RTS option is supported. The section of XBD you quoted refers only to the two symbolic onstants listed in that bullet point: _POSIX_CHOWN_RESTRICTED and _POSIX_NO_TRUNC. Both of these represent options from older version of POSIX which are now mandatory (which is also true of the following bullet-point). This change was made in POSIX.1-2001 for alignment with the FIPS-151 standard. > The change I made worked fine in -STABLE. > However, in -CURRENT, this test breaks, because _POSIX_REALTIME_SIGNALS > is defined, but it is -1. POSIX.1-2001 requires that this constant be so defined if the option is not supported. See the <unistd.h> section. > 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. It's also wrong when used in conjunction with POSIX options. The correct test is as follows: If the option constant is not defined, you really have no idea whether the option is available or not. If the corresponding sysconf(3) key *is* defined, then you might be able to use sysconf(3) or getconf(1) to determine whether the option is supported. You will probably still need to check for the headers and functions manually, because the implementation is not being forthcoming and probably doesn't implement the function even if sysconf() claims it does. If the option constant is defined as -1, the option is guaranteed not to be supported, and the implementation provides neither the library functions nor the header files necessary to compile a program which makes use of the option. If the option constant is defined as a positive value, the option is guaranteed to be supported under all configurations of the system. The library functions and header files are supplied for use with the C compiler, c99(1) (or c89(1) for older POSIX standards). For some functions, additional library specifications must be provided on the c99 command line (see the standard for details). The precise valu of the option constant will tell you what version of the option is supported; for POSIX.1-2001, the option constant if positive must usually be defined to 200112L. If the option constant is defined but zero, the option may or may not be supported depending on run-time configuration. Library functions and header files are supplied as described in the previous case, but applications must call sysconf(3) with the appropriate key to determine at run time whether the option is supported on the system as currently configured. These rules have changed somewhat as the POSIX standards have evolved, but this is the current state of affairs as set out in 1003.1-2001. Hope this helps. -GAWollman 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?200210100549.g9A5nFLn060516>