> #ifndef _POSIX_OPTION
>
> the application can determine via a runtime call the level of platform
> support for an option but cannot reliably compile any code that might use
> the option since we do not know whether compile support of any form
> is there in this case.
>
> #else
>
> the application can determine reliably the level of platform support at
> compile time
>
> #endif
I was frustrated by dealing with undefined option macros when we
wrote Florist, our implementation of the POSIX 1003.5a/b/c Ada
API, and a 1003.5 conformance test suite. It would have been much
nicer if we could have relied on the option macros.
I think this was worst in the case of the test suite, since the
standard requires that if a given function is provided (even if
the option macro says the option is not supported) the function
must have correct semantics (returning, e.g., ENOSUP or doing the
requested operation correctly).
Some of the Ada code was generated by a C program, which depended
C code (mainly macros) generated by an an ugly configuration
script, built using the autoconf macro mechanism. The
configuration script had to run test compilations and linkages for
every function in the POSIX C API, to find out whether they were
supported, taking more than an hour to run on some machines.
I think what most of us were hoping for from the Unix/POSIX
standards process is that eventually -- at least for people who
are not writing applications to run on older versions of systems
-- we could reduce such multi-stage code-generating configuration
machinations, and rely directly on #ifdefs and the standard
macros. Even better, we might eventually get rid of the #ifdefs
and rely only on runtime feature-check calls.
--Ted
|