[Bug c/92720] cc1 accepts #include /dev/stdin inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92720 --- Comment #9 from Jonathan Wakely --- (In reply to Dennis Clarke from comment #7) > Sort of a vague idea there. Whatever "can be" means. However the file > /dev/stdin really is neither a "header" nor is it a "source" file. It could be. `echo "extern int i;"` would provide a valid source file to standard input. "source file" does not mean "regular file on a physical disk". > As people are saying, this is all "implementation" defined perhaps. I > feel that no file shall be included if it is neither a "source" file > nor a valid "header". No idea how one would verify such a condition at > the pre-processing translation stage. The compiler can't verify that. What's the difference between a header with a syntax error (which we obviously want the compiler to *attempt* to compile, and give a diagnostic) and a random file that isn't a header? > That seems to imply I could just as easily do an include of /dev/random. You can. Just don't expect it to compile. This seems like a case of "play stupid games, win stupid prizes".
[Bug c/92720] cc1 accepts #include /dev/stdin inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92720 --- Comment #8 from Dennis Clarke --- (In reply to jos...@codesourcery.com from comment #6) . . . > In turn, that section "Include Operation" has more details. It doesn't > mention includes with an absolute path, but I think that's because the > general concept of resolving a path relative to a directory, and how that > handles absolute paths, is one for the underlying operating system, not > for any particular application running on that operating system. I hope someone agrees that this seems like black magic : esther$ esther$ uname -a Linux esther 5.3.0-2-686 #1 SMP Debian 5.3.9-3 (2019-11-19) i686 GNU/Linux esther$ cat /proc/version Linux version 5.3.0-2-686 (debian-ker...@lists.debian.org) (gcc version 9.2.1 20191109 (Debian 9.2.1-19)) #1 SMP Debian 5.3.9-3 (2019-11-19) esther$ gcc --version gcc (Debian 9.2.1-19) 9.2.1 20191109 Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. esther$ ( /usr/bin/printf "\042"; dd if=/dev/urandom bs=16 count=1 2>/dev/null | od -Ax -t x1 -v | tr -d '\012' | cut -c8-54 | tr -d '\012';/usr/bin/printf "\042\n" ) | gcc -std=iso9899:1999 -pedantic -pedantic-errors -Wpedantic -fno-builtin -O0 -D_XOPEN_SOURCE=600 -o /tmp/wtf /tmp/wtf.c esther$ /tmp/wtf 1e e8 6e 82 6a a4 0b 66 0f d5 48 33 2a 86 21 6b esther$ Which makes one wonder what would happen if I were to merely include /dev/urandom directly. Dennis
[Bug c/92720] cc1 accepts #include /dev/stdin inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92720 --- Comment #7 from Dennis Clarke --- Looking at the document n1256 "ISO/IEC 9899:TC3 WG14/N125" ye C99 specifications we see section 6.10.2 Source file inclusion subsection 1 which almost seems clear : A #include directive shall identify a header or source file that can be processed by the implementation. Sort of a vague idea there. Whatever "can be" means. However the file /dev/stdin really is neither a "header" nor is it a "source" file. As people are saying, this is all "implementation" defined perhaps. I feel that no file shall be included if it is neither a "source" file nor a valid "header". No idea how one would verify such a condition at the pre-processing translation stage. However I also see : 5.1.1.2 Translation phases The precedence among the syntax rules of translation is specified by the following phases.[5] 1. Physical source file multibyte characters are mapped, in an implementation-defined manner, to the source character set (introducing new-line characters forend-of-line indicators) if necessary. Trigraph sequences are replaced by corresponding single-character internal representations. Where the footnote [5] states : 5 Implementations shall behave as if these separate phases occur, even though many are typically folded together in practice. Source files, translation units, and translated translation units need not necessarily be stored as files, nor need there be any one-to-one correspondence between these entities and any external representation. The description is conceptual only, and does not specify any particular implementation. That seems to imply I could just as easily do an include of /dev/random. Dennis
[Bug c/92720] cc1 accepts #include /dev/stdin inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92720
--- Comment #6 from joseph at codesourcery dot com ---
For the documentation of implementation-defined preprocessor behavior (as
required to be documented by a C implementation for anything the C
standard says is implementation-defined; in this case, where C11 6.10.2#2
and #3 refer to "How the places are specified or the header identified is
implementation-defined." and "searched for in an implementation-defined
manner"), see cpp.texi. It says:
@item Source file inclusion.
For a discussion on how the preprocessor locates header files,
@ref{Include Operation}.
In turn, that section "Include Operation" has more details. It doesn't
mention includes with an absolute path, but I think that's because the
general concept of resolving a path relative to a directory, and how that
handles absolute paths, is one for the underlying operating system, not
for any particular application running on that operating system.
[Bug c/92720] cc1 accepts #include /dev/stdin inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92720 --- Comment #5 from Dennis Clarke --- Glad someone looked at this. I was going to try again with LLVM/Clang and then a few other places on a few other architectures. Why bother? However if this is "implementation defined" then we should see a paragraph somewhere in a standards doc regarding this. Somewhere.
[Bug c/92720] cc1 accepts #include /dev/stdin inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92720 --- Comment #4 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > (In reply to Dennis Clarke from comment #0) > > This may require a bit of a dive into the specifications however > > an inline include of /dev/stdin seems wrong for some definition > > of wrong. > > There's no such thing as an "inline include", the preprocessor just > substitutes the content of the named file wherever a #include directive > appears. > > If that file happens to be /dev/stdin then it happens to be /dev/stdin. The actual mapping from a #include directive to a physical file is implementation defined, so it seems OK for one compiler to refuse to do include certain paths, and OK for another to do so.
[Bug c/92720] cc1 accepts #include /dev/stdin inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92720 --- Comment #2 from Jonathan Wakely --- (In reply to Dennis Clarke from comment #0) > This may require a bit of a dive into the specifications however > an inline include of /dev/stdin seems wrong for some definition > of wrong. There's no such thing as an "inline include", the preprocessor just substitutes the content of the named file wherever a #include directive appears. If that file happens to be /dev/stdin then it happens to be /dev/stdin.
[Bug c/92720] cc1 accepts #include /dev/stdin inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92720 --- Comment #3 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #1) > GCC does not check the files. > > >echo '\042hello botfelk\\n\042' > This one fails for me too: > In file included from t8.c:5:0: > /dev/stdin: In function ‘main’: > /dev/stdin:1:1: error: stray ‘\’ in program > /dev/stdin:1:2: error: invalid suffix "hello" on integer constant > /dev/stdin:1:11: error: expected ‘)’ before ‘botfelk’ > /dev/stdin:1:18: error: stray ‘\’ in program > /dev/stdin:1:19: error: stray ‘\’ in program > /dev/stdin:1:21: error: stray ‘\’ in program You need to use -e for GNU echo to interpret the \042 characters.
[Bug c/92720] cc1 accepts #include /dev/stdin inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92720 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- GCC does not check the files. >echo '\042hello botfelk\\n\042' This one fails for me too: In file included from t8.c:5:0: /dev/stdin: In function ‘main’: /dev/stdin:1:1: error: stray ‘\’ in program /dev/stdin:1:2: error: invalid suffix "hello" on integer constant /dev/stdin:1:11: error: expected ‘)’ before ‘botfelk’ /dev/stdin:1:18: error: stray ‘\’ in program /dev/stdin:1:19: error: stray ‘\’ in program /dev/stdin:1:21: error: stray ‘\’ in program
