[cfe-dev] [RFC] Make <atomic> and <stdatomic.h> explicitly incompatible

[Shoaib Meenai via cfe-dev]

I'd be in favor of making them explicitly incompatible. I ran into this recently, found the incompatibility quite surprising, and had to do a bunch of research (looking at the relevant standards, doing experiments across a bunch of compilers and standard libraries, etc.) to convince myself that it was expected behavior. An explicit error would be super nice.

From: cfe-dev <cfe-dev-bounces at lists.llvm.org> on behalf of cfe-dev <cfe-dev at lists.llvm.org>
Reply-To: Volodymyr Sapsai <vsapsai at apple.com>
Date: Wednesday, March 7, 2018 at 12:32 PM
To: cfe-dev <cfe-dev at lists.llvm.org>
Subject: [cfe-dev] [RFC] Make <atomic> and <stdatomic.h> explicitly incompatible

Hello all,

Currently atomics are available in C through <stdatomic.h> and in C++ through <atomic>. These headers have some common names, so using both of them in the same translation unit usually doesn’t work. The downside is that in some cases diagnostic can be overly verbose and overwhelming. For example, compiling just 2 lines

#include <stdatomic.h>
#include <atomic>

results in 68 errors.

I am proposing to make these headers explicitly incompatible, so we have just a single error telling so instead of multiple errors. What do you think?

Alternative solution is to make these headers compatible. But the consensus seems to be that it’s not the right solution. See https://reviews.llvm.org/D26376<https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D26376&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=f2XAChgmKGyURiNTGeNTF1t1Fpo5BLSqNdUKyYAZYeM&s=O1AIlpTPrgXe3-fXW3-VqVGTAUhg2qKBozM1iOtQhbE&e=> for more details. There is also a proposal P0943R0: Support C atomics in C++<https://urldefense.proofpoint.com/v2/url?u=http-3A__open-2Dstd.org_jtc1_sc22_wg21_docs_papers_2018_p0943r0.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=f2XAChgmKGyURiNTGeNTF1t1Fpo5BLSqNdUKyYAZYeM&s=iHKcnTreK84QBWD-j_3_n7ww5ON1-EzKzni3NgSgiaY&e=>.  As far as I can tell, my proposal doesn’t interfere with P0943R0 but will be obsolete if that proposal is accepted. Regardless of the future development I think it is still beneficial to have better diagnostics in the short term.

I am not providing concrete implementation yet, at first I want to know the opinion of the community on the matter.

Thanks,
Volodymyr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180307/a2ab09a8/attachment.html>