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

Reply via email to