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>