null filename handling question

[Guy Harris]

> I believe that AT&T fixed the System III null-path-component behavior
> with System V but am not sure (no System V kernels around here).

Answering this question, and the original question of "why are null strings
handled the way they are?":

The reason that a null string referred to the current directory in V7
(and possibly in earlier systems) is that it happened to work that way.
No more, no less.  System III and System V Release 2 (the only ones I checked;
S5 may do it also) have an explicit check for a null pathname and have
it return ENOENT.  4.2BSD, and some other systems, go in the opposite
direction; they changed the flow through "namei" so as to make it no
longer work "that way" - i.e., a null pathname no longer referred to ".".
So they put in code to explicitly make a null string refer to ".".  I
think this is a mistake, and that System N does it correctly, for the same
reason I think UNIX systems should keep location 0 out of processes' address
space if at all possible; it catches mistakes early.  (One of our programs
ran in full-screen mode and turned off public write permission on the user's
tty ("mesg n") by changing the mode to rw-------; however, sometimes the
pathname of the tty would be a null string (or a null pointer which
points to a null string on a VAX by pure happenstance; see previous comments
on location 0), and the current directory would have its execute permission
removed, with rather nasty consequences if it happened to be the user's
home directory.)

	Guy Harris (back from vacation)
	{seismo,ihnp4,allegra}!rlgvax!guy