Re: [PATCH v4 2/3] stdlib: Implement mbrtoc8(), c8rtomb(), and the char8_t typedef.

[Tom Honermann <tom@honermann.net>]

On 7/21/22 3:22 PM, Adhemerval Zanella Netto wrote:
>
> On 20/07/22 13:47, Tom Honermann wrote:
>> Confirmed that this issue can be easily reproduced outside the testsuite.
>>
>> $ cat t.cpp
>> #include <uchar.h>
>>
>> $ g++ --version
>> g++ (GCC) 13.0.0 20220720 (experimental)
>> ...
>>
>> $ g++ -c -I/path/to/glibc-char8_t/include -std=c++17 -Werror=c++20-compat t.cpp
>> In file included from t.cpp:1:
>> /home/tom/products/glibc-char8_t/include/uchar.h:38:23: error: identifier ‘char8_t’ is a keyword in C++20 [-Werror=c++20-compat]
>>     38 | typedef unsigned char char8_t;
>>        |                       ^~~~~~~
>> cc1plus: some warnings being treated as errors
>>
>> The char8_t typedef is currently guarded by:
>>
>> /* Declare the C2x char8_t typedef in C2x modes, but only if the C++
>>    __cpp_char8_t feature test macro is not defined.  */
>> #if __GLIBC_USE (ISOC2X) && !defined __cpp_char8_t
>> /* Define the 8-bit character type.  */
>> typedef unsigned char char8_t;
>> #endif
>>
>> __GLIBC_USE (ISOC2X) evaluates to true because gcc unconditionally defines _GNU_SOURCE. I believe otherwise, C++17 mode would only (or should only) imply __GLIBC_USE (ISOC11).
>>
>> Regardless, it seems that directives should be added to suppress the diagnostic. I tried prototyping such a fix, but it doesn't seem to work for me. I don't understand why.
> I have tried as well and I can't get to work either.  It would expect to work
> as we have done bits/stdlib-bsearch.h, could it be a gcc issue?

Yes, this appears to be a gcc issue. I spent some time looking at gcc 
source code, but didn't find anything obvious. I verified the same 
technique does work to suppress the similar warning issued for use of, 
e.g., constexpr, as an identifier when -Wc++11-compat is enabled. I 
found tests that exercise #pragma GCC diagnostic ignored "-Wc++-compat", 
but none for -Wc++20-compat (or -Wc++11-compat).

Tom.

>
>> $ diff -U3 uchar.h.old uchar.h
>> --- uchar.h.old 2022-07-20 12:37:55.544301692 -0400
>> +++ uchar.h     2022-07-20 12:43:21.124365563 -0400
>> @@ -34,8 +34,17 @@
>>   /* Declare the C2x char8_t typedef in C2x modes, but only if the C++
>>     __cpp_char8_t feature test macro is not defined.  */
>>   #if __GLIBC_USE (ISOC2X) && !defined __cpp_char8_t
>> +/* Suppress the C++20 compatability diagnostic regarding char8_t being a
>> +   keyword.  */
>> +#if defined __GNUC__ && 4 < __GNUC__ + (6 <= __GNUC_MINOR__)
>> +# pragma GCC diagnostic push
>> +# pragma GCC diagnostic ignored "-Wc++20-compat"
>> +#endif
>>   /* Define the 8-bit character type.  */
>>   typedef unsigned char char8_t;
>> +#if defined __GNUC__ && 4 < __GNUC__ + (6 <= __GNUC_MINOR__)
>> +# pragma GCC diagnostic pop
>> +#endif
>>   #endif
>>
>>   #ifndef __USE_ISOCXX11
>>
>> Tom.
>>
>> On 7/19/22 5:08 PM, Joseph Myers wrote:
>>> This change appears to introduce a failure of
>>> wcsmbs/check-installed-headers-cxx with GCC mainline, because uchar.h now
>>> produces:
>>>
>>> ../wcsmbs/uchar.h:38:23: error: identifier 'char8_t' is a keyword in C++20 [-Werror=c++20-compat]
>>>      38 | typedef unsigned char char8_t;
>>>
>>> (recall we want our installed headers to avoid warnings *without* relying
>>> on the default disabling of warnings in system headers).
>>>
>>> Unfortunately, GCC for C++ doesn't disable -Wc++20-compat inside
>>> __extension__ (unlike what the C front end does), so simply adding
>>> __extension__ to that declaration wouldn't help, but we could use
>>> diagnostic disabling pragmas (as already done in some installed headers).
>>>