Re: Gnulib's use of _Atomic, and hamt

On 2026-08-11 11:00, Bruno Haible wrote:
> 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).

The "small types" part is a big deal. More generally, the exact set of assumptions is important here.

As I understand it, MSVC doesn't support _Atomic unless you use the /experimental:c11atomics option (which has been "experimental" for years!), and even then it still defines __STDC_NO_ATOMICS__ (which means ordinary portable code won't use _Atomic), and even then it supports only lock-free atomic types up to 64 bits.

Also, as I discovered when fixing hamt.h, for ease of header portability between C and C++, it's not enough for an implementation to support the _Atomic type qualifier (e.g., 'char *_Atomic p;') as that doesn't work in C++; it should also support the _Atomic type specifier (e.g., '_Atomic (char *) p;'). However, the latter syntax wasn't added to C++ until C++23, which it's too early to assume yet (and even then one must #include <atomic>). Although we could try to backport _Atomic(T) to older C++ versions, that might be tricky to do correctly as strictly speaking, it would rely on undefined behavior in C++20 and earlier. In gnulib/lib/hamt.h I instead invented and used GL_HAMT_ATOMIC, as I didn't want to assume C++23 when compiling with C++. Not an entirely satisfactory solution but there 
 it is.



> 
> _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,

With Oracle Developer Studio 12.6 (the only Sun C that supports C11 _Atomic) there's another issue: if you compile with -xatomic=studio, the resulting programs are dynamically linked to .../developerstudio12.6/lib/compilers/atomic/libstatomic.so.1 even if they never use _Atomic. So there would be a benefit to compiling modules and linking programs with -xatomic=studio only when needed. Unfortunately Gnulib doesn't really support that.

Also, as mentioned above, it's not just Sun C that needs special flags. With MSVC you need /experimental:c11atomics. With 32-bit Clang you might need -latomic; at least, that's the case for Clang 22.1.8 (Fedora 22.1.8-4.fc44) when I compile with "clang -march=i386 -m32". There are similar issues with recent GCC in some distros. Almost surely there are similar problems with other compilers.

All in all, it appears that Gnulib is quite a way away from being able to use _Atomic(T) easily in portable code. Maybe 10 or 15 years from now; or maybe even earlier if someone puts in the time to make it work, but not today, and certainly not if you really need _Atomic to work rather than merely want a best effort.


>> 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.
I doubt whether hamt is a good guinea pig. Nobody uses it. If the changes I just made to it are incorrect, likely nobody will care. I found problems with it only because I was doing global code inspection, not because I was actually testing it. And most of the problems I found (see examples above) I did not fix.

Part of the issue with hamt is that it might work in a multithreaded system, and it might not. The _Atomic stuff is optional, after all, and hamt builds just fine if it knows _Atomic is not supported, and if so it'll almost always work, but sometimes it won't. Not exactly a recipe for confidence.

Another thought: if hamt is general-purpose, why doesn't Guile use it? Does Guile have special needs that hamt doesn't satisfy? If so, wouldn't it be better to extend hamt to support Guile?

Without a real use, the hamt code is pretty much just an orphan time-sink, as far as I can see.