[PATCH 1/3]: C N2653 char8_t: Language support

[Tom Honermann]

On 6/11/21 12:53 PM, Jakub Jelinek wrote:
> On Fri, Jun 11, 2021 at 12:20:48PM -0400, Tom Honermann wrote:
>> I'm open to whatever signaling mechanism would be preferred.  It took me a
>> while to settle on _CHAR8_T_SOURCE as the mechanism to propose as I didn't
>> find much for other precedents.
>>
>> I agree that having _CHAR8_T_SOURCE be implied by the -fchar8_t option is
>> unusual with respect to other feature test macros.  Is that what you find to
>> be weird and inconsistent?
>>
>> Predefining __SIZEOF_CHAR8_T__ would be consistent with __SIZEOF_WCHAR_T__,
>> but kind of strange too since the size is always 1.
>>
>> Perhaps a better approach would be to follow the __CHAR16_TYPE__ and
>> __CHAR32_TYPE__ precedent and define __CHAR8_TYPE__ to unsigned char.  That
>> is likewise a bit strange since the type would always be unsigned char, but
>> it does provide a bit more symmetry.  That could potentially have some use
>> as well; for C++, it could be defined as char8_t and thereby reflect the
>> difference between the two languages.  Perhaps it could be useful in the
>> future as well if WG14 were to add distinct char8_t, char16_t, and char32_t
>> types as C++ did (I'm not offering any prediction regarding the likelihood
>> of that happening).
> C++ already predefines
> #define __CHAR8_TYPE__ unsigned char
> #define __CHAR16_TYPE__ short unsigned int
> #define __CHAR32_TYPE__ unsigned int
> for -std={c,gnu}++2{0,a,3,b} or -fchar8_t (unless -fno-char8_t), so I agree
> just making sure __CHAR8_TYPE__ is defined to unsigned char even for C
> is best.
> And you probably don't need to do anything in the C patch for it,
> void
> c_stddef_cpp_builtins(void)
> {
>    builtin_define_with_value ("__SIZE_TYPE__", SIZE_TYPE, 0);
> ...
>    if (flag_char8_t)
>      builtin_define_with_value ("__CHAR8_TYPE__", CHAR8_TYPE, 0);
>    builtin_define_with_value ("__CHAR16_TYPE__", CHAR16_TYPE, 0);
>    builtin_define_with_value ("__CHAR32_TYPE__", CHAR32_TYPE, 0);
> will do that.

Thank you; I had forgotten that I had already done that work.  I 
confirmed that the proposed changes result in __CHAR8_TYPE__ being 
defined (the tests included with the patch already enforced it).

Tom.

>
> 	Jakub
>