On Fri, 16 Aug 2024, Jakub Jelinek wrote: > On Fri, Aug 16, 2024 at 01:43:58AM +0200, Jakub Jelinek wrote: > > My reading of it wasn't that whether it is > > # embed < h-char-sequence > embed-parameter-sequence[opt] new-line > > or > > # embed < h-char-sequence > embed-parameter-sequence[opt] new-line > > or > > # embed pp-tokens new-line > > depends solely on the filename part in there, but also whether > > embed-parameter-sequence is syntactically valid (if specified). > > But if so, doesn't that mean that also > #define foo bar > #define bar baz > #define limit suffix (1 > #embed <foo/bar.inc> limit ) > should be treated as > #embed <bar/baz.inc> suffix (1) > ? > I'd think that for filenames that would be quite surprising.
I think the header-name preprocessing token still gets recognized inside #embed, so preventing macro expansion inside the filename, because there are no identifier preprocessing tokens inside that filename. Just as #define EMPTY #define foobar stdio #include <foobar.h> EMPTY doesn't end up including <stdio.h> after macro expansion. (There is the subsequent implementation-defined process for combining preprocessing tokens between < and > into a header name, so allowing a header name to result from macro expansion without needing a header name as an argument to the macro, but no such process to split up a header name before macro expansion.) -- Joseph S. Myers josmy...@redhat.com
