On Tue, Sep 9, 2025 at 4:41 PM Jonathan Wakely <jwak...@redhat.com> wrote:
> 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." > I do not think this is relevant here, this is about the default value for template parameter counting_semaphore, which affects only uses of counting_semaphore<>. I wanted to add something usable beyond depends on platform, so defined that counting_semaphore<>::max will be at least numeric_limits<int>::max(), so you have an idea where to put your own value. For other specializations, there is nothing implementation defined in standard, you just get something greater or equal than. https://eel.is/c++draft/thread.sema#cnt-4 > ? > >
