On Tue, 9 Sept 2025 at 15:57, Tomasz Kaminski <tkami...@redhat.com> wrote: > > > > 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<>.
Ah yes, I forgot how the "least_max_value" works and where it is relevant. We could potentially say it's numeric_limits<atomic_signed_lock_free::value_type>::max() which is true in practice, but I think what your patch says is better. > 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 Yes, and that's where it varies depending on N==1 or N > 1. OK, patch is good for trunk with the typos fixed, thanks.
