Re: ISO C 23, <stdlib.h>, and once_flag

[Jeffrey Walton]

On Sat, Mar 25, 2023 at 5:05 PM Bruno Haible <bruno@clisp.org> wrote:
>
> In ISO C 23,
>   - the type 'once_flag',
>   - the macro ONCE_FLAG_INIT,
>   - the declaration of function 'call_once'
> are all available from <stdlib.h>, not only from <threads.h>.
>
> 1) This makes it clear that often call_once is needed in an application
> without also needing mutexes. For this reason, I'm moving the 'call_once'
> function definition out of the 'mtx' module, into a module of its own.
>
> 2) The requirement to have 'once_flag' defined in <stdlib.h> would mean
> that Gnulib's stdlib.h replacement would have
>   - to include <pthread.h> on Unix platforms, and
>   - to include <windows.h> on native Windows.
>
> Each of the two includes would cause a lot of trouble to users:
>   - for <pthread.h>, by having many more cases of header file recursion
>     (we had that often, and the workarounds were always ad-hoc),
>   - for <windows.h>, by defining lots of identifiers in the namespace.
>
> This is not worth the trouble, given that the workaround — include
> <threads.h> instead of <stdlib.h> — is in the realm of ISO C and
> very simple. I'm therefore not implementing ISO C 23 compatibility
> on this point. We can revisit it in 10 years or so; then hopefully
> some platforms will have restructured their header files and will
> define 'once_flag' in <stdlib.h>.

Be careful of call_once.

Several years ago I cut over to C++11's call_once. The problem was, it
only worked reliably on 32-bit and 64-bit Intel platforms. It was a
disaster on Aarch64, PowerPC and Sparc. I had to back it out.

The problems happened back when GCC 6 and 7 were popular. The problem
was due to something sideways in glibc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146

If you want a call_once-like initialization then rely on N2660:
Dynamic Initialization and Destruction with Concurrency.

Jeff