On Mon, 8 Sept 2025 at 12:41, Tomasz Kamiński <tkami...@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." ?
