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

[Drew Adams]

The following expressions all return true (on Windows, at least). I imagine
that this is by design (it is an old policy), but I don't understand the
reason for this.

 (file-exists-p "")
 (file-readable-p "")
 (file-writable-p "")

How often would someone want a null filename to be considered to correspond
to an existing, readable, or writable file?

This means that code that tests a filename needs to do something like this:

 (and (not (string= "" name)) (file-readable-p name))

For example, when prompting a user for the name of a readable file, I guess
you need to do something like this:

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

Why?

This behavior also seems to contradict the doc strings. They say clearly
that the file with the given name really exists, is really readable, or is
really writable.

Also, the doc strings and the manual say nothing about using a default
directory (yes, apparently) or whether the FILENAME argument must include a
directory (it need not, apparently).