[libcxx-commits] [libcxx] [libc++][Android] Always redirect <stdatomic.h> to <atomic> (PR #143036)

[Aaron Ballman via libcxx-commits]

AaronBallman wrote:

> I do not believe it's a non-conforming extension to allow `<stdatomic.h>` to redirect to `<atomic>` pre-C++23, because stdatomic.h is not a standard header in C++ prior to C++23.

It was intentional that there not be a `stdatomic.h` header in C++17 and C++20. Both had a footnote which said:

>  It is intentional that there is no C++ header for any of these C headers: <stdatomic.h>, <stdnoreturn.h>, <threads.h>.

I don't know if the intent was that it's non-conforming to provide one of those intentionally ignored headers or not. I think it's kind of moot, frankly.

Keep in mind that this is circa 2010 in both committees; C++ was type safe but not nearly to the extent it is these days. The original idea was that `_Atomic(T)` and `std::atomic<T>` were going to be "the same thing" under the hood and thus completely interchangeable. Both committees figured you could `#define _Atomic(T) std::atomic<T>` in C++ and that's good enough to work for compatibility so long as the ABI works out in terms of size, alignment, passing, etc. Clang took that one step further and decided that `_Atomic(T)` should just work in C++ (particularly because it's a conforming extension to have the type due to its reserved spelling).

Regardless of how we ended up here...

> Overall, this whole situation is awful 

Strong +1 to this sentiment, unfortunately. The situation is just as awful in the committees -- we were sold that atomics would be compatible between C and C++ and it's 15+ years later and that's still not actually true and both committees continue to modify the standard in this space without coordinating with the other committee. So "nonconformance" isn't super compelling to me in this case (personally) without more justification; I'm much more concerned with not breaking existing code in either language.

https://github.com/llvm/llvm-project/pull/143036