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