стандартные символьные константы и типы (standard symbolic constants and types)
Обоснование (Rationale)
As POSIX.1‐2008 evolved, certain options became sufficiently
standardized that it was concluded that simply requiring one of
the option choices was simpler than retaining the option.
However, for backwards-compatibility, the option flags (with
required constant values) are retained.
Version Test Macros
The standard developers considered altering the definition of
_POSIX_VERSION and removing _SC_VERSION from the specification of
sysconf() since the utility to an application was deemed by some
to be minimal, and since the implementation of the functionality
is potentially problematic. However, they recognized that support
for existing application binaries is a concern to manufacturers,
application developers, and the users of implementations
conforming to POSIX.1‐2008.
While the example using _SC_VERSION in the APPLICATION USAGE
section does not provide the greatest degree of imaginable
utility to the application developer or user, it is arguably
better than a core file or some other equally obscure result. (It
is also possible for implementations to encode and recognize
application binaries compiled in various POSIX.1-conforming
environments, and modify the semantics of the underlying system
to conform to the expectations of the application.) For the
reasons outlined in the preceding paragraphs and in the
APPLICATION USAGE section, the standard developers elected to
retain the _POSIX_VERSION and _SC_VERSION functionality.
Compile-Time Symbolic Constants for System-Wide Options
POSIX.1‐2008 includes support in certain areas for the newly
adopted policy governing options and stubs.
This policy provides flexibility for implementations in how they
support options. It also specifies how conforming applications
can adapt to different implementations that support different
sets of options. It allows the following:
1. If an implementation has no interest in supporting an option,
it does not have to provide anything associated with that
option beyond the announcement that it does not support it.
2. An implementation can support a partial or incompatible
version of an option (as a non-standard extension) as long as
it does not claim to support the option.
3. An application can determine whether the option is supported.
A strictly conforming application must check this
announcement mechanism before first using anything associated
with the option.
There is an important implication of this policy. POSIX.1‐2008
cannot dictate the behavior of interfaces associated with an
option when the implementation does not claim to support the
option. In particular, it cannot require that a function
associated with an unsupported option will fail if it does not
perform as specified. However, this policy does not prevent a
standard from requiring certain functions to always be present,
but that they shall always fail on some implementations. The
setpgid() function in the POSIX.1‐1990 standard, for example, is
considered appropriate.
The POSIX standards include various options, and the C-language
binding support for an option implies that the implementation
must supply data types and function interfaces. An application
must be able to discover whether the implementation supports each
option.
Any application must consider the following three cases for each
option:
1. Option never supported.
The implementation advertises at compile time that the option
will never be supported. In this case, it is not necessary
for the implementation to supply any of the data types or
function interfaces that are provided only as part of the
option. The implementation might provide data types and
functions that are similar to those defined by POSIX.1‐2008,
but there is no guarantee for any particular behavior.
2. Option always supported.
The implementation advertises at compile time that the option
will always be supported. In this case, all data types and
function interfaces shall be available and shall operate as
specified.
3. Option might or might not be supported.
Some implementations might not provide a mechanism to specify
support of options at compile time. In addition, the
implementation might be unable or unwilling to specify
support or non-support at compile time. In either case, any
application that might use the option at runtime must be able
to compile and execute. The implementation must provide, at
compile time, all data types and function interfaces that are
necessary to allow this. In this situation, there must be a
mechanism that allows the application to query, at runtime,
whether the option is supported. If the application attempts
to use the option when it is not supported, the result is
unspecified unless explicitly specified otherwise in
POSIX.1‐2008.
