Don't include <stdatomic.h> in C++
OPENSSL_C11_ATOMIC is both computed in crypto/internal.h and also
defined externally. This is a remnant of C11 atomics were an opt-in
feature.
If defined externally, this means OPENSSL_C11_ATOMIC might be defined
when built as C++. That, in turn, causes <stdatomic.h> to be included in
C++ mode. At least one of our users toolchains has a <stdatomic.h> that
is incompatible with C++. We don't get anything out of including it, so
just gate the include on !defined(__cplusplus) for now.
Things to look into as follow-up:
- Fix build files to stop defining OPENSSL_C11_ATOMIC. Prior to
https://boringssl-review.googlesource.com/c/boringssl/+/59847, it was
still serving a purpose: in server builds, if autodetection fails, we
would rather fail to build than accidentally fallback to locks.
There is no lock fallback anymore.
- Fix that toolchain so their <stdatomic.h> is C++-compatible. It's
certainly not C++23-conformant. I suspect it's also not
C++11-conformant, but I'm not positive.
Change-Id: I13bcd8380efeb87b9f9cc439fe24a743e48aec60
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59985
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
diff --git a/crypto/internal.h b/crypto/internal.h
index 9edfd0e..4b7d82c 100644
--- a/crypto/internal.h
+++ b/crypto/internal.h
@@ -165,6 +165,10 @@
#define OPENSSL_C11_ATOMIC
#endif
+#if defined(OPENSSL_C11_ATOMIC)
+#include <stdatomic.h>
+#endif
+
// Older MSVC does not support C11 atomics, so we fallback to the Windows APIs.
// When both are available (e.g. clang-cl), we prefer the C11 ones. The Windows
// APIs don't allow some operations to be implemented as efficiently. This can
@@ -176,10 +180,6 @@
#endif
#endif // !__cplusplus
-#if defined(OPENSSL_C11_ATOMIC)
-#include <stdatomic.h>
-#endif
-
#if defined(OPENSSL_WINDOWS_THREADS) || defined(OPENSSL_WINDOWS_ATOMIC)
OPENSSL_MSVC_PRAGMA(warning(push, 3))
#include <windows.h>
