[PATCH] libstdc++: Document remaining C++20 implementation-defined behavior.

[Jonathan Wakely]

On Mon, 8 Sept 2025 at 12:41, Tomasz Kamiński <tkaminsk@redhat.com> wrote:
>
> I have double checked that implementation-defined behavior in the [compliance]
> (whether the implementation is freestanding) and [stringbuf.const] (initialization
> of sequence pointers) are indeed null, and there are no corresponding entires in
> eariel standards.

"earlier"

>
> libstdc++-v3/ChangeLog:
>
>         * doc/html/manual/status.html: Regenerate.
>         * doc/xml/manual/status_cxx2020.xml: Add more entires.
> ---
> OK for trunk? Should I also backport it, if so how far?

Just trunk is fine, we need to document this stuff to be conforming,
but we aren't claiming conformance to C++20 for the branches.

However, a few typos and a suggestion at the end ...

> diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
> index 3539de3cc4b..e646215e092 100644
> --- a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
> +++ b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
> @@ -1464,6 +1464,12 @@ and <function>chrono::parse</function> is supported since 14.1.
>        the 2020 standard.
>     </para>
>
> +   <para>
> +      <emphasis>16.4.2.4 [compliance]</emphasis> The implementation is
> +      freestanding if <code>-ffreestanding</code> compiler flag is used,

"if the"

> +      and hosted otherwise.
> +   </para>
> +
>     <para>
>        <emphasis>16.4.2.4 [compliance]</emphasis>
>        The support for always lock-free integral atomic types and presence of
> @@ -1472,6 +1478,21 @@ and <function>chrono::parse</function> is supported since 14.1.
>        target.
>     </para>
>
> +   <para>
> +      <emphasis>27.5.11 [time.duration.io]</emphasis>
> +      The <literal>"μs"</literal> (<literal>"\u00b5\u0073"</literal>) is used
> +      for <code>std::micro</code> <code>Period::type</code> if macro

"if the macro"

> +      <code>_GLIBCXX_USE_ALT_MICROSECONDS_SUFFIX</code> is defined to value

"to a value"

> +      other than zero before inclusion of the <code>chrono</code> header,
> +      <literal>"us"</literal> is used otherwise.
> +   </para>
> +
> +   <para>
> +      <emphasis>29.8.2.2 [stringbuf.cons]</emphasis> Sequence pointers are
> +      initialied to null pointers by

"initialized", and "by the"

This is PR80676 and I have a patch to change the constructor to use
the SSO capacity, but your patch is correct for now.

> +      <code>basic_stringbuf(ios_base::openmode)</code> constructor.
> +   </para>
> +
>     <para>
>        <emphasis>31.7.1 [atomics.ref.generic.general]</emphasis>,
>        <emphasis>31.7.3 [atomics.ref.int]</emphasis>,
> @@ -1503,6 +1524,14 @@ and <function>chrono::parse</function> is supported since 14.1.
>        <code>alignof(value_type)</code>.
>     </para>
>
> +   <para>
> +      <emphasis>32.7.3 [thread.sema.cnt]</emphasis> The value of default
> +      argument for the <code>least_max_value</code> depends on the target
> +      operating system and platform, however the value of
> +      <code>counting_semaphore<>::max()</code> is greater than or equal
> +      to <code>numeric_limits<int>::max()</code>.
> +   </para>

For std::binary_semaphore (a.k.a std::counting_semaphore<1>) the max
is 1, so would it make sense to say something like:

"however the value of counting_semaphore<N>::max() for N > 1 is at
least INT_MAX, and for N <= 1 it is 1."
?