On 8/31/22 10:35, Jakub Jelinek wrote:
On Tue, Aug 30, 2022 at 11:37:07PM +0200, Jakub Jelinek via Gcc-patches wrote:
If
#define z(x) 0
#define a z(
int x = a\NARG);
is valid in C and C++ <= 20 then
#define z(x) 0
#define a z(
int x = a\N{LATIN SMALL LETTER A WITH ACUTE});
is too and shall preprocess to int x = 0; too.
Which would likely mean that we want to only handle it in identifiers if
in C++23 and not actually treat it as an extension except in literals.
Jason, your toughts about that?
Trying to read again the current C++23 wording, I'm afraid that outside of
the literals both the delimited escape sequences and named universal
characters are a complete nightmare for diagnostics.
Because the wording is that only valid universal character names are
replaced by their corresponding characters.
Ill-formed is only if the hexadecimal digit sequences are valid but
represent a number that is not a UCS scalar value, or represent a control
character.
So, I think we can't reject even
#define z(x) 0
#define a z(
int b = a\u{});
int c = a\u{);
int d = a\N{});
int e = a\N{);
int f = a\u123);
int g = a\U1234567);
int h = a\N{LATIN SMALL LETTER A WITH ACUT});
Couldn't C++23 say at least that if a valid named-universal-character
doesn't designate any character then the program is ill-formed?
It could be more explicit, but I think we can assume that from the
existing wording; it says it designates the named character. If there
is no such character, that cannot be satisfied, so it must be ill-formed.
So, we could reject the int h case above and accept silently the others?
Why not warn on the others?
GCC 12 accepts all these without warning, current trunk rejects the h
case with error and accepts the rest without a warning, clang trunk
emits warnings on all cases but the last and rejects the h case with
an error.
Jakub
