Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!mcvax!ukc!reading!onion!riddle!domo
From: domo@riddle.UUCP (Dominic Dunlop)
Newsgroups: comp.unix.wizards
Subject: Re: /bin/test and stat(2) [actually meaning of null pathname]
Message-ID: <501@riddle.UUCP>
Date: Tue, 20-Oct-87 06:12:47 EST
Article-I.D.: riddle.501
Posted: Tue Oct 20 06:12:47 1987
Date-Received: Sun, 25-Oct-87 22:20:51 EST
References: <9723@brl-adm.ARPA> <1063@moscom.UUCP> <30667@sun.uucp>
Reply-To: domo@riddle.UUCP (Dominic Dunlop)
Followup-To: comp.unix.wizards
Organization: Sphinx Ltd., Maidenhead, England
Lines: 37
Keywords: POSIX, 1003.1, SVID, X/OPEN, FIPS, standards
Summary: POSIX workshop resolving vagueness on null pathnames even now.

In article <30667@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes:
>> If JJ Programer only wants to code on SysVid Compliant machines then
>> they can assume stat("",&b) and test -d ""  will return ENOENT and false
>> resepctively.
>
>Guess again; the SVID says nothing more than "a null string is undefined and
>*may* be considered an error" (emphasis mine).  There will certainly be
>SVID-compliant systems that treat a null string as a synonym for ".".

Yes.  This is a problem, isn't it?  In fact draft 11 of IEEE 1003.1 (POSIX),
like the SVID, lets conforming implementations go either way.  For good (?)
measure, the X/OPEN Portabilty Guide, edition 2, volume 2, is also
definitively vague: ``The null string is undefined, and may be considered
an error.''  At least we have a consensus that the way to handle this issue
is to punt.  Or do we?  I just received mail from the IEEE 1003.1 committee
saying that this unsatisfactory state of affairs is to be
discussed at the POSIX Implementor's Workshop, to be held today (20th
October) and tomorrow at the Sheraton Potomac in Gaithersburg, MD.
Apparently POSIX won't cut it as a Federal Information Processing Standard
unless this and a number of other vaguenesses are cleared up.  If I
interpret the mail correctly, 1003.1 may end up saying one of three things:

1. Null pathname invalid (specific value returned in errno -- ENOENT??)

2. Null pathname means current directory

3. _POSIX_PATHNAME_NULL defined somewhere (<posix.h>??) by implementor iff
   null pathname means current directory, otherwise null pathname
   invalid.

As I haven't been paying as much attention to developments as perhaps I
should, it could be that my interpretation is off by miles.  Could somebody
who attended the meeting please post a summary based on something other
than guesswork?  Thanks.

Dominic Dunlop
domo@sphinx.co.uk  domo@riddle.uucp