When ERN XBDd5-367 (jjh20) was rejected back in 2001, I did not pursue
the matter because the standard was in the final stages of being
approved. But I agree with those who think there is a problem with
the existing scheme.
The trouble starts with the sentence "If these are undefined, the
fpathconf(), pathconf(), or sysconf() functions can be used to
determine whether the option is provided for a particular invocation
of the application." (XBD 2001 edition lines 14023-14025, 2004 edition
lines 14143-14145)
There are two problems with this sentence.
The first is that it is application usage and should not be in the
normative text. The application does not need permission from this
sentence to use the functions: it can use them even if the option
constants are defined as -1 or greater than zero.
The second problem arises from the fact that in real life, application
programmers are concerned not just with portability between
implementations that conform to one revision of POSIX, but also with
other implementations which may, for example, conform to an earlier
version of POSIX. In this context, the sentence is not true, because
the _PC_* or _SC_* macros needed to use fpathconf(), pathconf(), or
sysconf() might not be defined.
In a new revision, I think the existing constants should be required to
be defined (if the implementers can define the PC_* and SC_* constants,
they can define the _POSIX_* constants) and a new scheme should be used
for any new options. This new scheme should have three cases: unknown
option (constants undefined), possibly implemented, and certainly
implemented. I would avoid using zero as one of the values for the last
two cases so that the programmer can take advantage of the fact that the
C pre-processor treats undefined macros as having the value zero.
Until then, an example should be added to Application Usage to show how
to test one of the constants, conditionally including a header, and
using one of the *conf() functions.
Jon Hitchcock
|