Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!pyrdc!gmu90x!dolqci!vrdxhq!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: special cases and zero-length strings (was Re: To . or not to .)
Message-ID: <9203@mimsy.UUCP>
Date: Tue, 3-Nov-87 16:50:39 EST
Article-I.D.: mimsy.9203
Posted: Tue Nov  3 16:50:39 1987
Date-Received: Sat, 7-Nov-87 08:24:35 EST
References: <648@tut.cis.ohio-state.edu> <722@wacsvax.OZ> <9171@mimsy.UUCP> <1973@killer.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 65

[Background:  I claimed that */, a//b, and //x all have the
zero-length string as a name component, and that SysV should
therefore reject them.  Those of you who are tired of this debate
should stop reading this article now.]

In article <1973@killer.UUCP> jfh@killer.UUCP (The Beach Bum) writes:
>Sorry to do this to you Chris, but that works just fine here.

Actually, I had understood that to be the case.  I was in fact
cloaking a philosophical argument for "" => current directory.

[implementation deleted]

>... my understanding of the original bug was if the first `c' was
>'\0', the current I-node, which was the current directory, since
>c != '/'.  That's why "" == . in the old world.  Consider "/", where
>the first character returned is '/', and after that, the next is '\0'.

Yes, consider it well!

>But '/' is still quite special ...

And (philosophically speaking) I consider this a fault.  The fewer
special cases imbedded in a naming system, the better; *no* special
cases is ideal.  If you wish to have both relative and absolute
naming, however, you must either provide two different name lookup
routines (in which case a name is no longer simply a string, but
rather a string and a selector) or add a special case.  Unix uses
the special case, and ultimately I must agree with this particular
choice.

Now given the special case that a leading separator `/' indicates
an absolute path name, the proper (I claim) way to regard the name
lookup is this:  First peek at the first character.  If it is `/',
consume it, and begin at the root; otherwise begin at the current
directory.  From then on every `/' is always a separator.  Traverse
the file system by looking up every name component (including null
components such as the one in a//b) and stop only when you run out
of components or cannot find a component in the current directory
as of the most recent separator.

As it happens, the null name is not in fact stored in any directory.
But this is an *implementation detail*: it is entirely unrelated
to the apparent operation of the naming system.  Like `.', the null
name refers to the current directory as of the most recent separator.

If you want to disallow null names, to be consistent you should (I
claim) disallow them everywhere:  If open("") returns ENOENT, it
should do so only because the null name is not stored in the current
directory.  But since the null name is not stored in the root
directory, open("/") should also return ENOENT.  open("a//b") and
open("x/") should likewise fail.

*To be consistent, the null name must be nowhere or the null name
must be everywhere.*  Since most people agree that `/' suffices to
name the root directory (`/.' being the next alternative), I say
that the null name is everywhere, and open("") should begin at the
current directory and find the null name and stop.  System V's name
lookup routine claims that the null name is everywhere *except*
the current directory, and at that, only the first time it looks
there!  (open("./" succeeds and opens the current directory.)
*This* is the behaviour to which I object.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris