FD-STREAM is a subclass of FILE-STREAM

[Tobias C. Rittweiler]

The way SBCL's streams are set up, all FD-STREAMS are FILE-STREAMS. This is
deeply wrong, and makes things harder for everyone who want to reason about pathnames
associated with streams (FILE-STREAMS are valid pathname designators.)

For example, Slime's inspector tries to use PATHNAME on any kind of FILE-STREAM
object which a socket is, too. However, PATHNAME signals an (obscure)
error when being tried on a socket. People expressed discomfort that sockets are not
really file-streams.

(As a stopgap measure we might return pathnames based on the FD: /dev/fd/n -- but
that sucks too.)

[Chaitanya Gupta (mail-chaitanyagupta)]

Besides socket based FD-STREAMS, you can also not inspect STREAM-ERROR objects (which use such streams) as the Slime inspector tries to use the pathname here too.

[Douglas Katzman (dougk)]

The theoretical musings that go in our issue tracker are inactionable.
To say "This is deeply wrong" seems rather contentious considering the Unix viewpoint that everything is a file.

What ever happened to the best practice of reporting a bug "Here is what I did, Here is what I expected to happen, here is what actually happened, here is how I tried to resolve the problem"
Closing as incomplete.

[Tobias C. Rittweiler (tcr)]

Hi Douglas,

It is exactly the issue that it is not actually accurate that "everything is a file" on Unix -- assuming a usual denotion of "file" to have a name in the file system, certainly that is the denotion in the CLHS (see below).

More accurate would be to say that on Unix, "everything is a file descriptor".

And there are file descriptors which do not have a name in the filesystem: such as sockets or unnamed pipes. And nowadays a lot more on Linux like the results from timerfd, signalfd, etc.

In Common Lisp, a FILE-STREAM is strictly tied to a /file/ which is defined in the glossary as a "named entry in a file system".

So on a Unix system, a FILE-STREAM should be a subclass of an FD-STREAM and not the other way around. (If an implementation can do so conformingly, I would not be able tell off hand.) In that regard, "[it] is deeply wrong".

The bug report did mention what the actual, concrete issue was that prompted the report: Slime's inspector likes to call PATHNAME on a stream that is-a FILE-STREAM.

It does so on sound grounds: PATHNAME takes a /pathname designator/ which is a /stream associated with a file/ which is "a file stream".

And apparently in 2008, invoking PATHNME on a socket's stream which is-a FD-STREAM, is-a FILE-STREAM, resulted in a cryptic error being signalled.

It seems that nowadays, that error message is not cryptic at all anymore and Slime has been patched to wrap an IGNORE-ERRORS around its call to PATHNAME to guard against this implementation issue of SBCL.

[Tomas Hlavaty (q-tom-o)]

On Sat 19 Dec 2020 at 20:28, "Tobias C. Rittweiler" <email address hidden> wrote:
> And there are file descriptors which do not have a name in the
> filesystem: such as sockets or unnamed pipes. And nowadays a lot more
> on Linux like the results from timerfd, signalfd, etc.

This seems wrong.

All file descriptors have a name in the filesystem.

> The bug report did mention what the actual, concrete issue was that
> prompted the report: Slime's inspector likes to call PATHNAME on a
> stream that is-a FILE-STREAM.
>
> It does so on sound grounds: PATHNAME takes a /pathname designator/
> which is a /stream associated with a file/ which is "a file stream".
>
> And apparently in 2008, invoking PATHNME on a socket's stream which
> is-a FD-STREAM, is-a FILE-STREAM, resulted in a cryptic error being
> signalled.
>
> It seems that nowadays, that error message is not cryptic at all
> anymore and Slime has been patched to wrap an IGNORE-ERRORS around its
> call to PATHNAME to guard against this implementation issue of SBCL.

Maybe PATHNAME should return /proc/self/fd/<fd> if no other name is
associated with the stream?

[Richard M Kreuter (kreuter)]

I think there are two arguments here that SBCL's current behavior is non-conforming, and perhaps an argument that the behavior is suboptimal even if allowed. I'll present contrary views for each, and ask that returning /dev/fd or /proc/self/fd paths never be considered.

1. There's a claim that all file streams are pathname designators. I believe there are only 2 passages in ANSI that are binding here: the glossary entry for "pathname designator" and section 20.1.1.

The glossary entry uses a grammatical construction common to most designators' definitions, "an object that designates a <foo>; that is, an object that denotes a <foo>, and that is one of: <type1> (denoting <a particular foo according to rule1>)... or a <typeN> (denoting <a particular foo according to ruleN>)". The respective "(denoting ...)" phrases define, piecewise, "denotes" in the phrase "an object that denotes a <foo>". Consider "function designator": either a function (denoting itself) or a symbol (denoting the function named by that symbol in the global environment). I think it's uncontroversial that not all symbols are function designators, because for some symbols, there is no function described by the phrase "the function named by that symbol in the global environment". (In other words, the grammatical construction makes the definition self-defining; likewise for "class designator", "package designator".) If we apply this syntactic analysis to "pathname designator", we can say that a stream associated with a file is a pathname designator only if there exists a pathname that was the pathname used to open the file. IOW, the definition does not require each file stream to denote a pathname any more than "function designator" requires each symbol to denote a function.

As for 20.1.1, it says about a stream associated with a file that "such streams can be used as pathname designators". I suppose that this could be interpreted as a requirement that every file stream must be a pathname designator, but I don't think that's only way to read the sentence. "Can be used as" isn't textually identical to "are"; perhaps the difference signifies something. For example I'd say the sentence "symbols can be used as function designators" can be judged a true descriptive statement about symbols, but an incomplete description of how symbols designate functions, and so, while true, would not imply that all symbols are function designators.

So I'm not convinced all file streams are required to denote pathnames.

2. There's been some argumentation about whether a socket ought to count as a "file", i.e., "a named entry in a file system". (I think this reasoning rests on shaky ground: file systems were outside ANSI's scope to define rigorously. But let's give it a fair shake.)

First, I observe that ANSI's "file system" is described only as "a facility which permits data to be stored in named files..." I believe the "which" clause should be understood as nonrestrictive, i.e., a facility having additional capabilities can be a file system. (Very many historical operating systems had the idea that the file namespace could include names for disks, terminals, printers, batch queues, robot arms, o...