On Fri, Aug 16, 2024 at 05:14:42PM +0000, Joseph Myers wrote:
> On Fri, 16 Aug 2024, Jakub Jelinek wrote:
>
> > Ok. So for now, should I work on a patch variant which tries to follow
> > what is in C23 right now?
>
> Not sure how useful having such a patch variant would be until we have a
> better idea of what the desired semantics actually are.
BTW, another question is whether __has_embed is macro expanded or not.
Because
6.10.1/13 says that
"Prior to evaluation, macro invocations in the list of preprocessing tokens
that will
become the controlling constant expression are replaced (except for those macro
names
modified by the defined unary operator), just as in normal text."
so the only special case there is defined, not
__has_embed/__has_include/__has_c_attribute.
But then 6.10.1/11 has:
"The identifiers __has_include, __has_embed, and __has_c_attribute
shall not appear in any context not mentioned in this subclause."
so wonder if
#define HAVE_STDIO_H __has_include (<stdio.h>)
#if HAVE_STDIO_H
#endif
isn't invalid (although both gcc and clang accept it).
Anyway, 6.10.1/1 still has the two different forms of
__has_include/__has_embed and in 6.10.1/5 says
"The second form of the has_include expression and has_embed expression is
considered only if the
first form does not match, in which case the preprocessing tokens are processed
just as in normal
text."
So, if we do the scan whole #embed line for syntax without macro expansion
and based on that decide whether to macro expand that or just
limit/gnu::offset args and prefix/suffix/if_empty only when actually using
those, shall the same be done also for __has_embed, or always do macro
expansion there, or do it depending on whether __has_embed itself comes
from a macro or not? Maybe for __has_include it doesn't really matter,
but for __has_embed it does.
Jakub
