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

[Tom Honermann]

On 7/22/22 1:24 AM, Tom Honermann via Libc-alpha wrote:
> On 7/21/22 4:56 PM, Adhemerval Zanella Netto wrote:
>>
>> On 21/07/22 17:51, Tom Honermann wrote:
>>> 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.
>>>
>> In any case I think the fix below is the correct way (in fact I don't 
>> see
>> another way so I am assuming a compiler issue here).
> I agree. I debugged gcc tonight and discovered what the problem was. 
> I'll submit a patch to gcc.

A patch has been submitted to gcc to correct '#pragma GCC diagnostic 
ignored' based suppression for -Wc++20-compat diagnostics. See the 
thread at https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598736.html.

Tom.