RE: Null filename ("") is considered to correspond to an existing, readable, and writable file?

[Drew Adams]

    > I already said that I assumed this was "by design".  I asked
    > what the design _advantage_ is. No answer, so far.

    A file name "" is extrememly rare, so how we behave when facing such
    a situation should be driven by the two following goals:
    1 - avoid risks (e.g. try not to introduce security holes).
    2 - try not to spend too much code&time on it.
    I.e. the behavior should mostly be determined by the way the
    code makes it work, as long as it makes sense and is not dangerous.

See below on "extremely rare". Those general design goals are fine, but they
don't speak specifically to the advantage of _this_ particular design. They
don't, for example, show an advantage over considering "" to not be a file
name (neither relative nor absolute). Is there some security advantage? Does
it take less time or code?

    If you could give us some background as to why you care so much
    about the way Emacs handles a file named "", maybe you'd be taken
    more seriously.

As I said, I am not interested in trying to _change_ the current behavior. I
wanted to _understand_ the rationale for it. I wanted to understand the
advantage it provides - I thought perhaps I was missing something. Based on
the lack of an answer to my query (so far), I guess there is no advantage
and I wasn't missing anything. That's OK; now I know. (If anyone does see an
argument for the design, I'm still interested.)

My main point in writing about this, which I keep repeating is my main
point, is that the _doc_ is not clear enough.

As to why I "care so much" and the "extreme rarity" of an empty file name,
I've already given this simple example (twice):

 (while (or (string= "" name) (not (file-readable-p name)))
   (setq name (read-file-name prompt...)))

The example shows:

 - A program often (not extremely rarely) needs to account for user-input
filenames. Whereas "" as a name might be rarely constructed in a program,
and is impossible as the name of a real file, user input can require a
program to deal with the empty-name case.

 - The confusion that could (and will) arise from the fact that there is no
explanation of the file-name arg for these functions whose names suggest
that they act differently than they do. It shows, too, what you must do to
deal correctly with the problem. Such an example, by itself, would in fact
be enough as doc to dispel possible confusion: it shows that
`file-readable-p' by itself does not guarantee that the name names a
readable file.

I propose:

 1) Documenting the file-name arg in each of these functions,
    mentioning:

    a) that the name can be either relative (to the
       `default-directory') or absolute, and

    b) specifically reminding readers that "" is a relative
       file name, so, provided `default-directory' is an existing
       (or readable, or writable) directory, the function will
       return non-nil for ""

 2) More clearly expressing the general definition of a relative
    file name, specifically pointing out that "" is considered a
    legitimate relative file name, and that the name is relative
    because it does not start with / or ~.