Re: [PATCH] C++ P0482R6 char8_t: declare std::c8rtomb and std::mbrtoc8 if provided by the C library

[Tom Honermann <tom@honermann.net>]

On 6/23/21 1:27 PM, Jonathan Wakely wrote:
> N.B. please CC gcc-patches as well when sending patches to this list.
Ah, yes, I think you've reminded me of that before.
>
> On Mon, 7 Jun 2021 at 03:16, Tom Honermann via Libstdc++
> <libstdc++@gcc.gnu.org> wrote:
>> This patch completes implementation of the C++20 proposal P0482R6 [1] by
>> adding declarations of std::c8rtomb() and std::mbrtoc8() if provided by
>> the C library.
>>
>> Autoconf changes determine if the C library declares c8rtomb and mbrtoc8
>> at global scope when uchar.h is included and compiled with -fchar8_t;
>> _GLIBCXX_USE_UCHAR_CHAR8_T is defined if so.  The <cuchar> header
>> re-declares these functions in the std namespace only if available and
>> the C++20 __cpp_char8_t feature test macro is defined.
>
> Thanks, Tom. I'm surprised that there's no __cplusplus dependency
> here. Some C libraries aren't going to declare these new functions
> unconditionally, only for C2x and C++20 modes. Your new configure
> check tests for them with -std=c++11 -fchar8_t (and the implicit
> -D_GNU_SOURCE on GNU/Linux) which doesn't guarantee they'll be
> available.
>
> This isn't a problem for your glibc patches, because you do:
>
> +#if defined _CHAR8_T_SOURCE || defined __cpp_char8_t
> +# define __GLIBC_USE_CHAR8_T   1
>
> But consider a hypothetical libc that only define the new functions
> for C2x/C++20, ignoring the __cpp_char8_t set by -fchar8_t. For such a
> libc the configure test using -std=c++11 -fchar8_t will fail, and
> libstdc++ won't declare the functions in namespace std even though
> they are in libc.
>
> Shouldn't the configure test use -std=c++20 instead to check that
> they're available for C++20 mode, and then in <cuchar> guard the using
> declarations for ::c8rtomb and ::mbrtoc8 with #if __cplusplus >=
> 202002L ?
>
> That would mean they're not declared in <cuchar> pre-C++20 when using
> -fchar8_t, but that seems a lesser problem than having them not
> declared in C++20 when they are actually present in libc. Maybe to
> solve that we need two configure macros (or one macro with multiple
> values), one that says the new functions are available for C++20, and
> another that says they are also available pre-C++20 if __cpp_char8_t
> is defined. Then <cuchar> can do something like:
>
> #if (__cplusplus >= 202002 && _GLIBCXX_USE_UCHAR_CXX20) \
>    || (__cpp_char8_t && _GLIBCXX_USE_UCHAR_CHAR8_T)
>
> Messy. Hmm.

Yup, you hit all the points I struggled with when coming up with an 
initial solution.  In the end, I settled on use of the C++ feature test 
macro being the only solution that worked in all cases, but it does 
imply that C libraries consistently follow suit.

Multiple probes seems like a reasonable option.  I think it is fair to 
assume that, if the declarations are present for -std=c++11 -fchar8_t, 
then they will also be present for later language standards.  So, if 
that probe fails, we can then probe again using just -std=c++20.

The conditional above would encounter errors for -std=c++20 -fno-char8_t 
for libc libraries that condition the declarations on the feature test 
macro.  I think it is reasonable to only enable the std namespace 
declarations if the __cpp_char8_t feature test macro is defined.

#if __cpp_char8_t \
     && (_GLIBCXX_USE_UCHAR_CXX11_CHAR8_T\
         || (__cplusplus >= 202002 &&_GLIBCXX_USE_UCHAR_CXX20))

Still messy, but I think this covers all the bases.

Tom.