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.
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.