Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!jbc
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-ID: <10061@cs.utexas.edu>
Date: 12 Jul 90 21:07:17 GMT
References: <9951@cs.utexas.edu>
Sender: jbc@cs.utexas.edu
Reply-To: std-unix@uunet.uu.net
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 24
Approved: jbc@cs.utexas.edu (Guest Moderator, John B. Chambers)

From:  Doug Gwyn <gwyn@smoke.brl.mil>


In article <9951@cs.utexas.edu> std-unix@uunet.uu.net writes:
>From:  Jason Zions <jason@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