On Mon, 10 Jan 2022 at 21:24, Tom Honermann via Libstdc++
<libstd...@gcc.gnu.org> wrote:
>
> On 1/10/22 8:23 AM, Jonathan Wakely wrote:
> >
> >
> > On Sat, 8 Jan 2022 at 00:42, Tom Honermann via Libstdc++
> > <libstd...@gcc.gnu.org <mailto:libstdc%2b...@gcc.gnu.org>> wrote:
> >
> > This patch completes implementation of the C++20 proposal P0482R6
> > [1] by
> > adding declarations of std::c8rtomb() and std::mbrtoc8() in
> > <cuchar> if
> > provided by the C library in <uchar.h>.
> >
> > This patch addresses feedback provided in response to a previous
> > patch
> > submission [2].
> >
> > Autoconf changes determine if the C library declares c8rtomb and
> > mbrtoc8
> > at global scope when uchar.h is included and compiled with either
> > -fchar8_t or -std=c++20. New
> > _GLIBCXX_USE_UCHAR_C8RTOMB_MBRTOC8_FCHAR8_T
> > and _GLIBCXX_USE_UCHAR_C8RTOMB_MBRTOC8_CXX20 configuration macros
> > reflect the probe results. The <cuchar> header declares these
> > functions
> > in the std namespace only if available and the _GLIBCXX_USE_CHAR8_T
> > configuration macro is defined (by default it is defined if the C++20
> > __cpp_char8_t feature test macro is defined)
> >
> > Patches to glibc to implement c8rtomb and mbrtoc8 have been
> > submitted [3].
> >
> > New tests validate the presence of these declarations. The tests pass
> > trivially if the C library does not provide these functions.
> > Otherwise
> > they ensure that the functions are declared when <cuchar> is included
> > and either -fchar8_t or -std=c++20 is enabled.
> >
> > Tested on Linux x86_64.
> >
> > libstdc++-v3/ChangeLog:
> >
> > 2022-01-07 Tom Honermann <t...@honermann.net
> > <mailto:t...@honermann.net>>
> >
> > * acinclude.m4 Define config macros if uchar.h provides
> > c8rtomb() and mbrtoc8().
> > * config.h.in <http://config.h.in>: Re-generate.
> > * configure: Re-generate.
> > * include/c_compatibility/uchar.h: Declare ::c8rtomb and
> > ::mbrtoc8.
> > * include/c_global/cuchar: Declare std::c8rtomb and
> > std::mbrtoc8.
> > * include/c_std/cuchar: Declare std::c8rtomb and std::mbrtoc8.
> > * testsuite/21_strings/headers/cuchar/functions_std_cxx20.cc:
> > New test.
> > *
> > testsuite/21_strings/headers/cuchar/functions_std_fchar8_t.cc:
> > New test.
> >
> >
> >
> > Thanks, Tom, this looks good and I'll get it committed for GCC 12.
> Thank you!
> >
> > My only concern is that the new tests depend on an internal macro:
> >
> > +#if _GLIBCXX_USE_UCHAR_C8RTOMB_MBRTOC8_CXX20
> > + using std::mbrtoc8;
> > + using std::c8rtomb;
> >
> > I prefer if tests are written as "user code" when possible, and not
> > using our internal macros. That isn't always possible, and in this
> > case would require adding new effective-target keyword to
> > testsuite/lib/libstdc++.exp just for use in these two tests. I don't
> > think we should bother with that.
> I went with this approach solely due to my unfamiliarity with the test
> system. I knew there should be a way to conditionally make the test
> "pass" as unsupported or as an expected failure, but didn't know how to
> go about implementing that. I don't mind following up with an additional
> patch if such a change is desirable. I took a look at
> testsuite/lib/libstdc++.exp and it looks like it may be pretty straight
> forward to add effective-target support. It would probably be a good
> learning experience for me. I'll prototype and report back.
Yes, it's very easy to do. Take a look at the
check_effective_target_blah procs in that file, especially the later
ones that use v3_check_preprocessor_condition. You can use that to
define an effective target keyword for any preprocessor condition
(such as the new macros you're adding).
Then the test can do:
// { dg-do compile { target blah } }
which will make it UNSUPPORTED if the effective target proc doesn't return true.
See https://gcc.gnu.org/onlinedocs/gccint/Selectors.html#Selectors for
the docs on target selectors.
I'm just not sure it's worth adding a new keyword for just two tests.
> >
> > I suppose strictly speaking we should not define __cpp_lib_char8_t
> > unless these two functions are present in libc. But I'm not sure we
> > want to change that now either.
>
> All of libstdc++, libc++, and MS STL have been defining
> __cpp_lib_char8_t despite the absence of these functions, so yeah, I
> don't think we want to change that.
OK, thanks.
