Hi Paul,
Paul Eggert wrote:
> Still, it appears that using _Atomic is dicey, at least in the Gnulib world
> which ports to older platforms. It's not clear to me whether or when
> Gnulib-using code should use _Atomic instead of Gnulib's simple-atomic
> module, for example.
On the contrary, I think we're not far from the point where we can bump the
minimum requirement from C99 to C11, and assume _Atomic (at least for small
types).
_Atomic is supported in
- gcc >= 4.9
- clang >= 4
- MSVC since 2026 [1],
- Fil-C (for small types only [2])
but
- requires a special compiler option with Sun C: -xatomic=studio,
- is ignored in TinyCC (tcc).
These are the distros with older GCC and clang versions:
GCC
3.3.2 Fedora 1
3.3.3 FreeBSD 5.2.1
4.1.2 CentOS 5
4.1.3 NetBSD 5
4.2.1 OpenBSD 6.x
4.4.7 CentOS 6
4.5.2 Slackware 13.37
4.7.2 kFreeBSD 7
4.6.2 openSUSE 12.1
4.7.1 Slackware 14
4.8.2 Ubuntu 14.04
4.8.5 CentOS 7
clang
3.8.0 FreeBSD 11
These are all end-of-life / out-of-support by now.
By the way, C11 atomics are nicely explained here: [3]
> First, it misspelled __STDC_NO_ATOMICS__, a bug that nobody has reported
> since hamt was added to Gnulib in 2021.
This is in a place where is does not matter, because the previous parts of
the #if condition already make sure that atomics are supported.
> Come to think of it, should we remove the hamt module from Gnulib?
I think we should keep it, because
- It's a general-purpose module.
- It's well documented [4].
- As you have just shown, we can use it as a "guinea pig" module for _Atomic
support, going forward.
Bruno
[1]
https://learn.microsoft.com/en-us/cpp/overview/what-s-new-for-msvc?view=msvc-170
[2] https://github.com/pizlonator/fil-c/issues/299
[3] https://beej.us/guide/bgc/html/split/chapter-atomics.html
[4]
https://www.gnu.org/software/gnulib/manual/html_node/Specialized-containers.html
