Path: utzoo!attcan!uunet!cs.utexas.edu!longway!std-unix
From: std-unix@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: POSIX flame...
Message-ID: <346@longway.TIC.COM>
Date: 17 May 89 13:59:08 GMT
Reply-To: uunet!aries.mitre.org!emery (David Emery)
Lines: 63
Approved: jsq@longway.tic.com (Moderator, John S. Quarterman)

Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Cc: std-unix, jsq@longway.tic.com, posix-ada-committee@grebyn.com
From: uunet!aries.mitre.org!emery (David Emery)

Shane writes:
>I guess that I may have said something a little strong here.  However,
>I am not ready to retract the statement.  There were many people at
>the Minneapolis meeting last fall who were not at all aquainted with
>the semantics of fundamental parts of Unix.  As an example, I would
>point to the misconception (by all of the group, if I remember
>correctly) that if you call getcwd() with a NULL pointer, and then
>later changed directories with a chdir(), then the string pointed to
>by that previous call would be replaced by the new pathname!  This is
>hardly a full understanding.

I don't remember this incident, and I was in Minneapolis last fall.  I
do know that there are places in 1003.1 (but getcwd() is NOT one of
them) where sometimes a call returns the address of memory which is
subject to change (i.e. memory inside the kernal, or whatever).  This
causes us major fits with respect to tasking, so we discussed how to
prevent/avoid/remove this problem.  I also remember some discussions
concerning the behavior of POSIX (not Unix) when NULL was passed as a
parameter to some routines.  This was often (particularly in Draft 12)
not well specified, even as being undefined.  (Incidently, calling
getcwd with a NULL pointer is clearly stated as being undefined in
1003.1 Drafts 12 and 13.) 

We in the Ada community (regardless of Unix-literacy) have a heluva
lot more experience with formal standards documents than the Unix
community.  Consider how most people learn Unix.  It's not by studying
SVID, but rather by learning an implementation.  Often there's
"implicit knowledge" about Unix that is not clear from the POSIX
standard (although 1003.1 Draft 13 was much improved over Draft 12 in
that regard.  There's at least on instance in 1003.2 where I objected
to something in the draft for that very reason.)  Ada has had a
validation suite before there were any implementations; we as a
community have learned a lot about standards and measuring
conformance.  (I can provide a few war stories...)

So, my point is this:  I still believe Shane's characterization is
unfair.  What he sees as "lack of understanding" may very well be an
attempt to fully explore the rammifications of the P1003.1 standard,
as opposed to "common knowledge about Unix".  

There are times when I think that the Unix community doesn't fully
understand their own semantics.  For instance, in the sample
Language Independent Definition, the type file_descriptor was made an
"opaque" type, one whose representation is not visible.  This won't
work.  In particular, if this type is not an integer, how do you
'name' file_descriptors that are not stdin, stdout and stderr?
Specifically, what is the 1003.1 meaning of 1003.2 I/O redirection for
FD 7, for instance?  As an active participant in many of these
discussions, I remember all the Unix arcana that wandered around the
1003.5 group trying to understand what the intended POSIX semantics
for file descriptors are.  We originally proposed that file_descriptor
be an Ada "private" type, but based on our knowledge of Unix, decided
that this would not work.  

				dave emery
				emery@mitre.org

Volume-Number: Volume 16, Number 43