Re: GCC reporting piped input as a security feature

[Jacob Bachmeyer]

Zack Weinberg wrote:
> On Tue, Apr 9, 2024, at 11:35 PM, Jacob Bachmeyer wrote:
>   
> > Jan Engelhardt wrote:
> >     
> > > On Tuesday 2024-04-09 05:37, Jacob Bachmeyer 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.)
> > > > >           
> ...
>
> How about `/dev/stdin/-` if no filename has been specified with #line or
> whatever, and `/dev/stdin/[filename]` if one has, where [filename] is
> the specified filename with all leading dots and slashes stripped,
> falling back to `-` if empty? /dev/stdin can be relied on to either not
> exist or not be a directory, so these shouldn't ever be openable.

I like that idea, but would suggest expanding on it as 
"/dev/stdin/[working directory]//-" or "/dev/stdin/[working 
directory]//[full specified filename]".  The double slash allows tools 
that care to parse out the specified filename, while the working 
directory preceding it provides a hint where to find that file if the 
specified filename is relative, but the kernel will collapse it to a 
single slash if a tool just passes the "[working directory]//[specified 
filename]" to open(2).  Since the working directory should itself be an 
absolute name, there would typically be a double slash after the 
"/dev/stdin" prefix.  Something like 
"/dev/stdin//var/cache/build/foopkg-1.0.0///usr/src/foopkg-1.0.0/special.c.m4" 
as an artificial example.


-- Jacob