On Fri, 16 Aug 2024, Jakub Jelinek wrote: > > 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). > > Is there an agreement on that?
I think it's understood to be what the words mean (apart from the recent discussion, also noted in February 2022 discussion - e.g. <https://www.open-std.org/jtc1/sc22/wg14/21635>). Whether it's desirable is another matter. Apart from likely wanting to be able to use macros within the prefix/suffix/if_empty arguments, it would also seem fairly reasonable to want to have a macro expanding to such parameters used with more than one directive. #define PARAMS prefix(X) suffix(Y) #embed "a" PARAMS #embed "b" PARAMS without needing to arrange for the directive not to look like one of the other forms before macro expansion. I've added this to my list of issues to file once we have an issue tracking system for the C standard in operation. > > > + 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.) > > Ok, will change that (there are really too many features and the table > already needs 147 columns before this change, so wanted to avoid adding new > stuff there unless necessary). My concern here is more with the use of the fields in cpp_options, than with the initialization of that from lang_flags. Maybe that large lang_defaults table isn't the optimal way of initializing all those cpp_options fields (although initializing CPP_OPTION (pfile, embed_directive) from l->warning_directive would also be awkward; the question is more whether computing the cpp_options fields with logic like "C from version X onwards, C++ from version Y onwards" would be an improvement on a table taking 147 columns). -- Joseph S. Myers josmy...@redhat.com
