PATHNAME-STREAMMAKE-TWO-WAY-STREAM or OPEN-STRING-STREAM. For many such streams, there is no simple way to coerce such a stream to a pathname.
Proposal PATHNAME-STREAM:FILES-OR-SYNONYM:
Clarify that the use of a stream as an argument that expects a pathname (as described on p413 of CLtL) only applies to streams that are originally opened by use of the OPEN or WITH-OPEN-FILE, or to synonym streams whose symbol is bound to such a stream. It is an error to attempt to obtain a pathname from a stream created with MAKE-TWO-WAY-STREAM, OPEN-STRING-STREAM, MAKE-ECHO-STREAM, MAKE-BROADCAST-STREAM, MAKE-CONCATENATED-STREAM, MAKE-STRING-INPUT-STREAM, MAKE-STRING-OUTPUT-STREAM.
The pathname used represents the name used to open the file. This may be, but is not required to be, the actual name of the file. The pathname used is the same as would be returned by the PATHNAME function.
Some implementations do not return a meaningful value for PATHNAME of a synonym stream.
PATHNAME of a synonym stream will have to change to allow it. Otherwise, since the proposal says only "is an error" rather than "signals an error", no implementations other changes are necessary.PATHNAME applies to synonym streams and returns the pathname of the stream designated.
This version of the proposal says yes, because CLtL p 329 says about synonym streams that "Any operations on the new stream ..." and does not say anything about exceptions; earlier on the page the phrase "synonym streams that pass all operations on" is used. This seems fairly unambiguous, although the word "operations" is not defined. There was a similar controversy about what CLOSE of a synonym stream means.
Note that there is currently no way portable to determine whether a stream has a pathname available.
The entire PATHNAME section needs work to clarify the intent and enable portable code. This is just a minor issue among the major ones.