The following was reported to me, and while I am not sure it is fully ISO C, I am told clang accepts this. % more test.* :::::::::::::: test.c :::::::::::::: #define BAR(x) x BAR( "<" #include "test.h" ">" ) :::::::::::::: test.h :::::::::::::: "foo" % ~/gcc-x86_64/bin/gcc -E test.c >/dev/null In file included from test.c:5:0: test.h:1:0: error: unterminated argument list invoking macro "BAR" "foo" ^
yes this code is undefined at compile time. GCC used to reject #define in a macro usage but it was decided we will accept that. I can find the old bugs if needed.
Six years later this is still unconfirmed :(. >(In reply to Andrew Pinski from comment #1) > yes this code is undefined at compile time. GCC used to reject #define in a > macro usage but it was decided we will accept that. I can find the old bugs > if needed. Shall this be then changed to WONTFIX (or INVALID)? It would be nice if someone provide some C standard reference if there is something regarding to this. Just for reference, I stumbled across this when analysing a CTF challenge solution (https://twitter.com/disconnect3d_pl/status/1212880292593229825) and wanted to do: #define TOSTR(a) #a #define hxp TOSTR( #include "flag" ); where the `flag` file contained: `hxp{flag}` (without backticks).
(In reply to Dominik Czarnota from comment #2) > Six years later this is still unconfirmed :(. Seven*. Oh those off by ones.
See e.g. ISO C99, 6.10.3/11, last sentence: "If there are sequences of preprocessing tokens within the list of arguments that would otherwise act as preprocessing directives, the behavior is undefined." Similarly for C++, see e.g. http://eel.is/c++draft/cpp.replace#11 So, the compiler can do anything with it.