Geoff Clare wrote:
> 3. Option might or might not be supported.
>
> The implementation does not advertise at compile time whether
> or not the option is supported. In this case, the fpathconf(),
> pathconf(), or sysconf() functions defined in the System
> Interfaces volume of IEEE Std 1003.1-2001 or the getconf
> utility defined in the Shell and Utilities volume of IEEE
> Std 1003.1-2001 can be used to retrieve the value of each
> symbol on each specific implementation to determine whether
> the option is supported. All headers, data types, and
> function interfaces required to compile and execute
> applications which use the option at runtime (after checking
> at runtime that the option is supported) shall be provided,
> but if the option is not supported they need not operate as
> specified. Utilities or other facilities required only for
> the option, but not needed to compile and execute such
> applications, need not be present."
This of course requires that an implementation ship *ALL* the header
files, function prototypes etc., even for options it has no intention of
ever supporting and signalled such intention by not even defining
the associated unistd.h macro.
Which, by the way, is historical practice that we *specifically* put back
into
UNIX03, after the problematic experience we had with requiring ENOSYS
stubs
back in UNIX98.
-------------------
Mark S. Brown
STSM, UNIX/Linux OS Standards
IBM Systems Group, Linux Technology Center
yyyyy@xxxxxxxxxx
|