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 what is implemented by the 3 implementations makes more sense,
is easier to implement and understand, but it would mean a DR.
Make just the filename part macro unexpanded or expanded based on whether
it matches
#embed < h-char-sequence > pp-tokens[opt] new-line
or
#embed " q-char-sequence " pp-tokens[opt] new-line
and if not use
#embed pp-tokens new-line
and say that the pp-tokens in the first two forms are macro expanded and
should be valid embed-parameter-sequence[opt] after macro expansion.
Because what is strictly specified right now means essentially lexing the
line (or more if \ is used at end of lines) twice, once with disabled macro
expansion, silently see if it matches the grammar and then depending on that
lex it again with or without macro expansion. Plus really unsure what to do
about the limit argument if it is balanced before expansion and not balanced
after it and whether to macro expand prefix/suffix/if_empty argument at all
and when if yes. If prefix/suffix/if_empty is macro unexpanded, it would be
a loop-hole how to introduce tokens without macro expansion into the source
(other than temporarily #undefining macros or using (foo) (args) to avoid
function-like macro expansion).
One could simply
#include <sys/stat.h>
#embed </dev/zero> if_empty (__linux__ = S_ISDIR (1, 2, 3, 4))
Jakub
