Re: file-readable-p returns t for empty string

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>       So what is expand-file-name to do with a
>     syntactically [invalid] name?  I see three possibilities:
> 
>     a) just leave it alone.  Someone else will have to deal with it.
>     b) return NIL
>     c) signal an error
> 
>     So I'd think a) the most expedient.
> 
> In this context, I am not sure what "just leave it alone" means.
> Do you mean, return ""?

Yes.

> That would violate the principle that expand-file-name always
> returns an absolute file name.

Absolute file names come in a variety of flavours.  They do not need
to start with "/".  For example, there are systems where they start
with the equivalent of "C:" before the first root /, or even
"/ftp@ftp.gnu.org:".  So what is it that qualifies an absolute file
name?  It is a file name that behaves the same regardless what the
current setting of your working directory is.  Now file operations on
"" are illegal regardless of what your current working directory is:
"" can thus be called an absolute file name in its own right.  It
would be a mistake to return "" on operating systems where "" indeed
*was* a valid file name.  But on such operating systems, the current
wide-spread nondistinction between "." and "./" would be much more
problematic, since the former would indicate the directory ".", and
the latter the file "" in the directory ".".

In short, as long as "" is an illegal file name in the operating
system in question, returning "" will correspond perfectly with the
principle that an absolute file name gets returned.

> So it would not be a good idea.
> 
> Returning nil would break lots of C code that assumes expand-file-name
> always returns a string.

Yes.

> Perhaps signalling an error is the best option.

expand-file-name is supposed to do a purely textual expansion, not to
signal errors.  It is not the task of expand-file-name to ascertain
the validity of file names.  I think that behavior would be more
surprising.  An error should only be signalled in unforeseeable
circumstances, IMO, like when ~username fails because /etc/passwd
cannot be opened.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de