Date: Thu, 10 Oct 2002 01:07:43 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Garrett Wollman <wollman@lcs.mit.edu> Cc: Craig Rodrigues <rodrigc@attbi.com>, freebsd-standards@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Problem detecting POSIX symbolic constants Message-ID: <3DA5354F.9BB3E54B@mindspring.com> References: <20021009222307.A9894@attbi.com> <200210100549.g9A5nFLn060516@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Garrett Wollman wrote: > <<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 That's what I said in the orignal posting. He needed to protect his use of the covered functions with that. [ ... ] > POSIX.1-2001 requires that this constant be so defined if the option > is not supported. See the <unistd.h> section. Is FreeBSD fully compliant with POSIX 1003.1-2001 compliant? > 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. Manual checking is no good. The only way to do that without relying on a feature test macro in FreeBSD is to nm the library, and look for the function symbols, or try linking a stub program, and check the exit status. FreeBSD has the prototypes, but doesn't have the code implementing the functions, which is where the probem started. It's a lot easier to check the macro: you don't have to write scripts to have portable source code. > 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. So the test is: #ifdef _POSIX_REALTIME_SIGNALS #if _POSIX_REALTIME_SIGNALS > 0 ...or, if you want to assume all preprocessors support "#if": #if defined(_POSIX_REALTIME_SIGNALS) && (_POSIX_REALTIME_SIGNALS > 0) I think the first is safer, in that if "#if" is not supported, it being an undefined preprocessor directive would be non-fatal, being in an uncompiled "#ifdef" block... > 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. Out of curiosity, where in the standard does it say this about zero? > 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. Yes, it clarifies things a lot. I wish you'd spoken up when he was originally asking how to perform the feature test at compile time (the sysconf(3) stuff for runtime support is pretty useless, IMO... you would fall back to not using the interface, I think, rather than put in a whole alternate set of code for it, with a whole alternate set of runtime overhead, which might add a bunch of compares to a "feature exists" flag). My posting was based on the information present in FreeBSD source files at the time the question was asked (and it's worked well, until -current defined it to be -1, without being otherwise fully compliant with POSIX 1003.1-2001, Grrrrr...). Would you recommend "#if", even though it meant the code would be less portable? The ACE framework is supposed to be portable to a lot of systems, some of which are running older compliers or not GNU C++. I'm positive that the first couple of years of the Oregon C++ compiler preprocessor didn't support "#if", for example. -- Terry 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?3DA5354F.9BB3E54B>