Weird mismatch between cdefs and stdatomic

LRN lrn1986@gmail.com
Mon Jan 28 14:02:00 GMT 2019


This[0] and this[1]. One header checks for atomic C/CXX extensions *and* for
the presence of a C++ compiler, while the other only checks for extensions.

The result is that the _Atomic() macro is *not* defined in cdefs.h when
compiled with C++, but the stdatomic.h atomic macros assume that it is, and try
to access the "__val" struct member, with predictable and sad results.

I just stumbled upon this while compiling OpenSSL, and wanted to see if anyone
else encountered this problem.

[0]
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/include/stdatomic.h;h=09c0cf73e0036537f54c6f5b86d854d1e77795b3;hb=HEAD#l36
[1]
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/include/sys/cdefs.h;h=ccb47ea4045d025b2ccd2319720879c5f37b3c0f;hb=HEAD#l290



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://cygwin.com/pipermail/cygwin/attachments/20190128/63943d92/attachment.sig>


More information about the Cygwin mailing list