Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!longway!std-unix
From: std-unix@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.0: POSIX Guide
Message-ID: <658@longway.TIC.COM>
Date: 2 May 90 04:43:45 GMT
References: <626@longway.TIC.COM> <636@longway.TIC.COM> <652@longway.TIC.COM>
Reply-To: std-unix@uunet.uu.net
Organization: U.S. Army Ballistic Research Laboratory
Lines: 27
Approved: jsq@longway.tic.com (Moderator, John S. Quarterman)

From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>

>From: guido@cwi.nl (Guido van Rossum)
>Also, even though we cannot guarantee 1003.1 conformance in all areas,
>we (the Amoeba group) do conform whereever we can.  All library
>functions, headers and constants required by 1003.1 will be there,
>although some functions will always return an error and others will not
>obey the exact prescribed semantics under certain conditions.  We
>believe we have done the best we could given the possibilities of our
>file system.

That's a reasonable approach, that should be pursued by other C
implementations in non-UNIX environments.  I'm doing something similar
for the C environment on my Apple running GS/OS, which cannot support
a resaonble emulation of fork() but can nicely support readdir() etc.
Such a "near-POSIX" environment reduces the problems of porting UNIX-
based applications into the environment, although there will be some
that are hopeless.

>Should we be punished for non-conformance or given some points for not
>deviating unnecessary?

Neither.  If someone truly requires 1003.1 conformance then you won't
be able to give it to them, but if all they want is 1003.2 then you're
in a good position.

Volume-Number: Volume 19, Number 93