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?