C23 addition of once_flag to <stdlib.h>

[Florian Weimer]

We made this change recently in glibc:

commit a7ddbf456d97ac8d1aa7afd735e196a1488bd874
Author: Joseph Myers <josmyers@redhat.com>
Date:   Wed Oct 1 15:15:15 2025 +0000

    Add once_flag, ONCE_FLAG_INIT and call_once to stdlib.h for C23
    
    C23 adds once_flag, ONCE_FLAG_INIT and call_once to stdlib.h (in C11
    they were only in threads.h, in C23 they are in both headers; this
    change came from N2840).  Implement this change, with a
    bits/types/once_flag.h header for the common type and initializer
    definitions.
    
    Note that there's an omnibus bug (bug 33001) that covers more than
    just these missing definitions.
    
    This doesn't seem a significant enough feature to be worth mentioning
    in NEWS.
    
    ISO C is not concerned with whether functions are in libc or
    libpthread, but POSIX links this to what header they are declared in,
    so functions declared in stdlib.h are supposed to be in libc.
    However, the current edition of POSIX is based on C17; hopefully Hurd
    glibc will have completed the merge of libpthread into libc (in
    particular, moving call_once) well before a future edition of POSIX
    based on C23 (or a later version of ISO C) is released.
    
    Tested for x86_64 and x86.

C++ has its own definition of std::once_flag in <mutex>.  The type is
different.  There are additional requirements for the C++ type, and we
were not aware of them when we defined once_flag (in <thread.h>) for
glibc.  Certainly we did not expect once_flag to end up in <stdlib.h>.

The question is what happens once C++ adopts C23 and adds std::once_flag
to <cstdlib>.  Should we use the C type for this, or the C++ type?  This
is a difficult choice.  It affects mangling.

Currently, my preferred outcome would be a DR against C and removal of
once_flag from <stdlib.h>.

Any other ideas?

Thanks,
Florian