Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.20/text0121.txt

Internet Message Format | 1990-08-02 | 1.8 KB

From:  Jason Zions <[e-mail]>

> Since it is planned that all these standards will be unified under the
> umbrella of ISO 9945-1 (or whatever future number the C-binding appears
> unders) it would seem more prudent to have a single feature-test macro,
> such as _POSIX_C_SOURCE, for which for increasing values expose the
> entire POSIX function namespace in historical order.  This would place
> no further requirements upon implementations.  Applications would be
> affected only when being modified to use POSIX extensions:  they would
> then have to honor not only the namespace reservation of the extension,
> but of all of POSIX at the time the extension was standardized.  Note
> that this requirement already exists for any other interfaces added by
> the working group which added the extension.

This makes the assumption that there is indeed a single POSIX name space,
to which pieces are added by the various working groups. This assumption,
while a reasonable one, is in fact not correct.

The various 1003.* working groups are *not* developing separate components
of an overall, integrated POSIX standard. Each POSIX standard stands alone
from all other POSIX standards *except* where that standard deliberately
requires dependencies. For example, 1003.2 is intended to be implementable
on systems which do not offer a 1003.1-compliant interface. So, a
strictly-compliant 1003.2 application *could not* assume the presence of
1003.1 symbols et al., and would be permitted to make use of names
otherwise reserved to 1003.1. Hence, there needs to be a separate
feature-test macro to activate the 1003.2 name space etc.

Worse yet, it appears that one of the POSIX Real Time Profiles may very
well require only a subset of 1003.1; how on earth does one represent
*that* using the _POSIX_C_SOURCE scheme?

Jason Zions


Volume-Number: Volume 20, Number 119