Torvald Riegel wrote: > IMHO, gnulib synchronization primitives should simply move towards the > semantics chosen by C++11 and more recent (if you dislike C++ for some > reason, just use the C++ semantics applied to C11; C is lacking behind > in terms of preciseness of the specification). > > Of course you can build your own, but that requires expertise and time.
gnulib is there to help adoption of POSIX and newer C standards. For instance, with gnulib you could use <stdint.h> since 2004, long before all platforms had it. (Even recently, in glibc 2.24, there was an issue with SIZE_MAX in <stdint.h> on s390 architecture.) gnulib does its best to shield its users from such portability problems. Regarding atomics, I agree it's good to have a standard in this area. But I fear gnulib can do less than it does for <stdint.h>, because the implementation is highly CPU and OS dependent. Just take a look at GCC's libatomic... gnulib code will, when all recently enough systems support it, be able to use <stdatomic.h>. But this will take years. Maybe 5 years, more likely something like 10 years. Bruno
