On Sat, 1 Mar 2025 at 11:36, rahl <rahl@xxxxxxxxxx> wrote: > > On 28 February 2025 20:57:50 UTC, Alejandro Colomar <alx@xxxxxxxxxx> wrote: > >On Fri, Feb 28, 2025 at 10:13:04AM +0000, rahl wrote: > >> I noticed that 'const' is used for both 'one' and 'zero' variables in > >> the Examples section demo code of manpage 'futex(2)'. > >> > >> The variables are both used in calls to > >> 'atomic_compare_exchange_strong()' where the 'const' is discarded as > >> it may write to the 'expected' parameter during a "failure" case. > > > >I don't understand what that function is. It doesn't have a manual > >page, and it's neither in /usr/include. It doesn't appear in the GCC > >manual either. And it's not described in ISO C. > > > >What is that function? > > > >I'd like to understand what we're calling to be able to understand how > >the calling code is wrong. > > atomic_compare_exchange_XXX() are defined in stdatomic.h and were introduced in C11 (ISO/IEC 9899:2011 I believe). > > The main online documentation for these that I'm currently aware of is at cppreference. > <https://en.cppreference.com/w/c/atomic/atomic_compare_exchange> > > >BTW, there seem to be other important bugs in that example program, > >which I don't understand either. Would you mind having a look at those > >(I'm assuming that you seem familiar with these atomic APIs)? See: > > You're right, there are more bugs. I'm however not so familiar with these functions, but I do have some help. > > The errors in question relate to a missing _Atomic qualifier for several variables and function parameters. > The documentation linked above should clarify this as well. > > It turns out these calls could be replaced with a compiler built-in (__atomic_compare_exchange_n) both for clang and gcc, which wouldn't have the above problem, and would also allow for the removal of 'stdatomic.h'. However, this didn't feel too in keeping with manpage example code. 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. > 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. 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.
