Multicharacter constants are not handled correctly in C or C++ before C++23

[Halalaluyafail3]

The following programs demonstrate the issues with how Clang handles multicharacter constants.

Program 1:

int main(void){
    L'ab';
}

Program 2:

int main(void){
    u'ab';
}

In program 1, multiple characters are used inside of a wchar_t character constant (prefixed with L). This is valid in C and valid in C++ before C++23. In program 2, multiple characters are used inside of a UTF-16 character constant (prefixed with u). This is valid in C before C23. This also applies to UTF-32 character constants (prefixed with U) as well. It seems that in Clang version 14 all language modes operate using the C++23 rules so that only character constants with no prefix can contain multiple characters. GCC correctly handles these cases, except that it doesn't reject program 2 in C23 which I have made a bug report for: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121739.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: None (Halalaluyafail3)

The following programs demonstrate the issues with how Clang handles multicharacter constants.

Program 1:

int main(void){
    L'ab';
}

Program 2:

int main(void){
    u'ab';
}

In program 1, multiple characters are used inside of a wchar_t character constant (prefixed with L). This is valid in C and valid in C++ before C++23. In program 2, multiple characters are used inside of a UTF-16 character constant (prefixed with u). This is valid in C before C23. This also applies to UTF-32 character constants (prefixed with U) as well. It seems that in Clang version 14 all language modes operate using the C++23 rules so that only character constants with no prefix can contain multiple characters. GCC correctly handles these cases, except that it doesn't reject program 2 in C23 which I have made a bug report for: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121739.

[frederick-vs-ja]

This was intended, see https://reviews.llvm.org/D106215. CC @cor3ntin.

It seems that we treated "implementation-defined" as "conditionally-supported", which is questionable.

[cor3ntin]

Indeed.
There is no good behavior for L'ab' - it was, depending on implementation equivalent to either L'a' or L'b' (ie it does not produce a semi sensible integer value like 'ab' would.
Therefore Clang makes that ill-formed in all language modes.

[Halalaluyafail3]

This was intended, see https://reviews.llvm.org/D106215. CC cor3ntin.

It seems that we treated "implementation-defined" as "conditionally-supported", which is questionable.

I don't understand how it can be interpreted like that. If the result of L'ab' being implementation-defined means an implementation can reject it, then couldn't 'ab' and sizeof(int) also be rejected for being implementation-defined?

There is no good behavior for L'ab' - it was, depending on implementation equivalent to either L'a' or L'b' (ie it does not produce a semi sensible integer value like 'ab' would.
Therefore Clang makes that ill-formed in all language modes.

Why does Clang try to reject valid programs based off of not having any good behavior in this one case? For example Clang will accept 'abcdefgh' with sizeof(int)<8 even though that can't give any good behavior.

[AaronBallman]

There were valid uses for multichar ASCII constants but those uses do not extend to non-ASCII characters, which is why C23 tightened the language up. This also keeps L consistent with u, U, and u8, which is a nice property.

I believe this is intentional, I don't think the behavior should be changed, and I think this should be closed as not a bug. WDYT @cor3ntin @tahonermann ?

[Halalaluyafail3]

There were valid uses for multichar ASCII constants but those uses do not extend to non-ASCII characters, which is why C23 tightened the language up. This also keeps L consistent with u, U, and u8, which is a nice property.

I believe this is intentional, I don't think the behavior should be changed, and I think this should be closed as not a bug. WDYT @cor3ntin @tahonermann ?

C23 still requires support for L'ab' character constants. C17 also required support for u'ab' and U'ab' character constants (u8 didn't exist for character constants).

[AaronBallman]

There were valid uses for multichar ASCII constants but those uses do not extend to non-ASCII characters, which is why C23 tightened the language up. This also keeps L consistent with u, U, and u8, which is a nice property.
I believe this is intentional, I don't think the behavior should be changed, and I think this should be closed as not a bug. WDYT @cor3ntin @tahonermann ?

C23 still requires support for L'ab' character constants.

No, those are implementation-defined and we decide to reject them.

C17 also required support for u'ab' and U'ab' character constants (u8 didn't exist for character constants).

No, those were also implementation-defined.

[Halalaluyafail3]

There were valid uses for multichar ASCII constants but those uses do not extend to non-ASCII characters, which is why C23 tightened the language up. This also keeps L consistent with u, U, and u8, which is a nice property.
I believe this is intentional, I don't think the behavior should be changed, and I think this should be closed as not a bug. WDYT @cor3ntin @tahonermann ?

C23 still requires support for L'ab' character constants.

No, those are implementation-defined and we decide to reject them.

C17 also required support for u'ab' and U'ab' character constants (u8 didn't exist for character constants).

No, those were also implementation-defined.

I don't understand how:

The value of a
wchar_t character constant containing more than one multibyte character or a single multibyte
character that maps to multiple members of the extended execution character set, or containing a
multibyte character or escape sequence not represented in the extended execution character set, is
implementation-defined.

Section 6.4.4.5 "Character constants" Paragraph 15 ISO/IEC 9899:2024

Can be interpreted to allow rejecting such character constants because they're described as implementation-defined. For example the value of LONG_MAX is implementation-defined, can an implementation simply not define it as a result? Even 'a' is implementation-defined, could an implementation hypothetically reject that too? If something having an implementation-defined value means an implementation can reject it then I don't see how one could write a strictly conforming program that does anything beyond just returning success.