Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: /bin/test and stat(2)
Message-ID: <6569@brl-smoke.ARPA>
Date: Thu, 15-Oct-87 10:07:43 EDT
Article-I.D.: brl-smok.6569
Posted: Thu Oct 15 10:07:43 1987
Date-Received: Sat, 17-Oct-87 07:36:10 EDT
References: <9767@brl-adm.ARPA> <673@unmvax.unm.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 36

In article <673@unmvax.unm.edu> mike@turing.unm.edu.UUCP (Michael I. Bushnell) writes:
>But "" is NOT "\0".

What the hell are you talking about?  If you write "" at the C source
code level, you have specified an array of one char containing just
a 0 byte; "\0" generates a 2-long char array containing two 0 bytes.
These will both be treated the same by any function that handles
null-terminated strings; in both cases the strings are considered to
contain 0 significant characters (not including the terminator).

At the shell level, a "" argument to a command turns into a similar
null-terminated string containing 0 characters before the terminator,
and that is the form seen in the argv[] array by the command's main()
function.  A "\0" argument normally is the same as "0" and therefore
contains one character (host code for a printable 0 digit, e.g. 48 in
ASCII) followed by a null terminator.  This doesn't seem to be what
you were referring to.

In summary, an "empty string" contains 0 significant characters.  If
it is encoded as a null-terminated string, then it has nothing stored
before the terminator.  This is much like the mathematical notion of
an empty set.

You cannot determine whether an empty string denotes a valid filename
or not from syntactic considerations; it does if the kernel interprets
it that way and it doesn't if the kernel doesn't.  Both types of UNIX
kernel behavior are widespread.

As to whether an empty string "should" have meaning as a pathname, and
what meaning it should have, that is a matter of opinion and judgement.
The original intent was for "" by itself to refer to the current working
directory; an argument could be made that this is just an instance of
a general algorithm for interpreting pathnames.  But an argument can
also be made that its meaning is not unambiguously determined by the
general rules, so that a special rule is necessary to uniquely nail
down the meaning of "".  Different systems nailed it down differently.