quoted

Well the example already relies on Linux-specific details of
syscall(2) and futex(2), and only GCC-compatible compilers are really
usable on Linux. So the GCC extensions could probably be assumed to
exist.

If you were writing pure C11 code intended to be portable, you
wouldn't be using SYS_futex anyway.

*Iff* C11 atomics were something we understand, maybe even just having
a working example that uses it would be worth it, even if Linux-only
stuff can do the same.

However...

quoted

quoted

The gcc docs are here:
<https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html>

The patch assumes that you can pass _Atomic int* to the futex syscall,
but I'm not sure if that's correct. The syscall expects an int.

Hmmm.

quoted

The C standard says "NOTE The representation of atomic integer types
need not have the same size as their corresponding regular types."

With GCC and Clang, _Atomic uint32_t does have the same representation
as unsigned, so it should work. I'm not an expert here though.

I can at least attest that the patched code compiles without complaint and appears to behave as expected.

Further, looking at the standard (at least C11 section 7.17.6), one can surmise that the _Atomic type for uint32_t will almost certainly always have the same representation and alignment as uint32_t; though I suppose we could have also used one of the documented guaranteed 32-bit types.

Considering that the example has been broken for a long time, and I've
asked for help in the glibc-help@ mailing list and nobody answered, and
you don't feel comfortable with it either, the best course of action is
to revert that commit.

Thanks for the review!

rahl, I'll do the revert myself, since it probably will have some merge
conflicts.  I'll put all of you in Reported-by, and send you a link to
the commit when I've done it.  Thanks!

Fair enough though. This has been a decent learning experience for me on a couple of fronts anyway.

Your time is appreciated. Thank you.

Hi Alex and Jonathan,