Alan D. Salewski wrote:
On 2024-04-08 22:37:50, Jacob Bachmeyer <jcb62...@gmail.com> spake thus:
Richard Stallman wrote:
[...]
In principle it could be posible to output something different to
describe this stramge situation explicitly. For instance, output "via
stdin" as a comment, or output `stdin/../filename' as the file name.
(Programs that optimize the file name by deleting XXX/.../ are likely
not to check whether XXX is a real directory.)
With the small difference that I believe the special marker should be
'<stdin>' (with the angle brackets, as it is now), this could be another
good idea. Example output: "[working directory]/<stdin>///[specified
filename]" or "[specified filename]///<>/[working directory]/<stdin>".
GDB could be modified to recognize either form and read the specified
file (presumably some form of augmented C) but report that the sources
were transformed prior to compilation. The use of triple-slash ensures
that these combined strings cannot be confused with valid POSIX
filenames, although I suspect that uses of these strings would have to
be a GNU extension to the debugging info format.
I do not think that the use of triple-slash (or any-N-slash) would
entirely prevent potential confusion with valid POSIX filenames, as
POSIX treats multiple slashes as equivalent to a single slash
(except in at the beginning of a path, where two slash characters
may have a different, implementation-defined meaning).
Since a pathname component name can basically contains any bytes
except <NUL> and <slash>, any token value chosen will likely have
some non-zero potential for confusion with a valid POSIX pathname.
Yes, this is the downside of the extreme flexibility of POSIX filename
semantics. Any C string is potentially a valid filename.
From SUSv4 2018[0] (update from 2020-04-30, which is what I happen
to have handy):
<quote>
3.271 Pathname
A string that is used to identify a file. In the context of
POSIX.1-2017, a pathname may be limited to {PATH_MAX} bytes,
including the terminating null byte. It has optional beginning
<slash> characters, followed by zero or more filenames separated
by <slash> characters. A pathname can optionally contain one or
more trailing <slash> characters. Multiple successive <slash>
characters are considered to be the same as one <slash>, except
for the case of exactly two leading <slash> characters.
</quote>
Rats, I had forgotten that detail. Emacs treats typing a second slash
as effectively invalidating everything to the left, I remembered that
some systems (and many URL schemes) use double-slash to indicate a
network host, and I expected that 3 slashes would mean starting over at
the root if that were ever presented to the kernel's filename resolution
service.
On the other hand, we could use multiple slashes as a delimiter if GCC
normalizes such sequences in input filename strings to single slash,
which POSIX allows, according to the quote above.
The simplest solution would be to simply document and preserve the
current behavior, which appears to be ignoring directives and recording
the working directory and "<stdin>" in the case of reading from a pipe,
and making sure that no normal build procedure for any GNU package pipes
source into the compiler.
-- Jacob
