On Thu, 15 Aug 2024, Jakub Jelinek wrote: > + D(embed, T_EMBED, STDC23, INCL | EXPAND) \
I'd like to query the macro expansion handling. My understanding is that a #embed directive only gets macro-expanded if it fails to match either of the forms # embed < h-char-sequence > embed-parameter-sequenceopt new-line # embed " q-char-sequence " embed-parameter-sequenceopt new-line and while the argument of a limit parameter gets processed (including macro expansion) like in a #if condition, that processing doesn't apply to the other standard parameters. (Maybe it *should* apply to prefix / suffix / if_empty so the pp-tokens in their arguments can include macros without needing to e.g. use a macro for the name of the file to embed as well, but that doesn't seem to be what the current wording says. There was some discussion of this on the reflector last month, ending with <https://www.open-std.org/jtc1/sc22/wg14//26110>.) Apart from any consequences for arguments of prefix/suffix/is_empty (where there is a plausible argument that the argument should get expanded at some point and that the current wording is undesirable for usability), this would also mean that e.g. #define LIMIT limit #embed "file" LIMIT(1) isn't valid because LIMIT doesn't get expanded (the syntax for non-expanded #embed is met, with an unknown parameter LIMIT), while #define limit ! #embed "file" limit(1) *is* valid, because limit doesn't get expanded (which may be convenient for usability - it means headers don't need to use __limit__ if using #embed, even if files including the header might have defined limit as a macro). > + if (CPP_PEDANTIC (pfile)) > + { > + if (CPP_OPTION (pfile, cplusplus)) > + cpp_error (pfile, CPP_DL_PEDWARN, > + "#%s is a GCC extension", "embed"); > + else if (!CPP_OPTION (pfile, warning_directive)) > + cpp_error (pfile, CPP_DL_PEDWARN, > + "#%s before C23 is a GCC extension", "embed"); I don't think warning_directive directive should be used here as the condition for diagnosing #embed as an extension; adding a separate embed_directive would be better. (Especially if a future C++ version ends up adding #embed; you could then use embed_directive as a condition for the pedwarn for both C and C++, whereas warning_directive wouldn't work as a condition for C++ since #warning is already in C++23.) -- Joseph S. Myers josmy...@redhat.com
