https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80005
Zack Weinberg <zackw at panix dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2019-06-12
CC| |zackw at panix dot com
Ever confirmed|0 |1
--- Comment #1 from Zack Weinberg <zackw at panix dot com> ---
Confirming. This has now bitten an attempt to use __has_include in glibc, see
discussion starting at
https://sourceware.org/ml/libc-alpha/2019-06/msg00254.html .
The proper fix, IMO, would be to apply the same special tokenization rules to
the argument of __has_include that are used for the argument of #include. This
is not exactly the same as "don't macro-expand the argument." Rather, in
#if !__has_include(<linux/memfd.h>)
the character sequence <linux/memfd.h> should be processed as a single
"h-char-sequence" token, in the language of C99 6.10.2. So there never is a
"linux" identifier token to macro-expand (nor is there a "memfd" or "h"
identifier).
However, if we instead have
#define HEADER_TO_LOOK_FOR "special.h"
#if __has_include (HEADER_TO_LOOK_FOR)
then HEADER_TO_LOOK_FOR should be macro-expanded.
Also, h-char-sequences and q-char-sequences are not string literals. For
example, if we have
#if __has_include("X11\Xlib.h")
the \X is _not_ an ill-formed escape sequence.
