Standards Update, IEEE 1003.1: System services interface
Doug Gwyn
gwyn at smoke.brl.mil
Fri Jul 13 07:07:17 AEST 1990
From: Doug Gwyn <gwyn at smoke.brl.mil>
In article <9951 at cs.utexas.edu> std-unix at uunet.uu.net writes:
>From: Jason Zions <jason at cnd.hp.com>
>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?
Shouldn't 1003.0 step in here and exert some coordination?
1003.1 was deliberately not split into "levels" a la COBOL,
and we meant it. A Real-Time extension could very well exist
(say, number 1003.123a) and not require that 1003.1 be specified,
but be useless in the absence of some subset of 1003.1 or equivalent,
just as a hosted C implementation on UNIX does not specify that
open() exist, but secretly requires a function with similar
properties in order to be implemented at all. If the problem is
that the extension wants to contradict some of 1003.1, then it is
an INCOMPATIBLE standard (i.e. one could not specify simultaneous
conformance with 1003.1 and 1003.123a), and I thought that standards
organizations prohibited that.
Volume-Number: Volume 20, Number 126
More information about the Comp.std.unix
mailing list