public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely@redhat.com>
To: Tom Honermann <tom@honermann.net>
Cc: "libstdc++@gcc.gnu.org" <libstdc++@gcc.gnu.org>,
	gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] C++ P0482R6 char8_t: declare std::c8rtomb and std::mbrtoc8 if provided by the C library
Date: Mon, 10 Jan 2022 13:23:22 +0000	[thread overview]
Message-ID: <CACb0b4mLX-UNkfmWs7njQkK8n1UpEJVTjCAG7XTXPP3Cy7f2Mg@mail.gmail.com> (raw)
In-Reply-To: <79037d6b-3c48-eb7b-030a-f388fb988187@honermann.net>

On Sat, 8 Jan 2022 at 00:42, 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() 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  <tom@honermann.net>
>
>         * acinclude.m4 Define config macros if uchar.h provides
>         c8rtomb() and mbrtoc8().
>         * 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.

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 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.

  reply	other threads:[~2022-01-10 13:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-08  0:42 Tom Honermann
2022-01-10 13:23 ` Jonathan Wakely [this message]
2022-01-10 21:23   ` Tom Honermann
2022-01-10 21:38     ` Jonathan Wakely
2022-01-11 20:13       ` Tom Honermann
  -- strict thread matches above, loose matches on Subject: below --
2021-06-07  2:16 Tom Honermann
2021-06-23 17:27 ` Jonathan Wakely
2021-06-24 19:35   ` Tom Honermann
2021-06-24 19:39     ` Jonathan Wakely
2021-06-25  2:56       ` Tom Honermann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACb0b4mLX-UNkfmWs7njQkK8n1UpEJVTjCAG7XTXPP3Cy7f2Mg@mail.gmail.com \
    --to=jwakely@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=libstdc++@gcc.gnu.org \
    --cc=tom@honermann.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).