From bd20800c22fc8402611b537287bd6948c3f2a5a8 Mon Sep 17 00:00:00 2001 From: David Benjamin Date: Fri, 29 Sep 2023 14:53:42 -0400 Subject: [PATCH] Add a comment for what compiler_test.cc is about It's probably worth explaining in a comment that this is about implementation-defined behavior, and why we consider it okay to make assumptions like uint8_t == unsigned char. Change-Id: Ia35248aef7895b0998831b6bac06993e845e6297 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/63285 Auto-Submit: David Benjamin Commit-Queue: Adam Langley Reviewed-by: Adam Langley --- crypto/compiler_test.cc | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/crypto/compiler_test.cc b/crypto/compiler_test.cc index 910233759..129ef7faf 100644 --- a/crypto/compiler_test.cc +++ b/crypto/compiler_test.cc @@ -22,6 +22,26 @@ #include "test/test_util.h" +// C and C++ have two forms of unspecified behavior: undefined behavior and +// implementation-defined behavior. +// +// Programs that exhibit undefined behavior are invalid. Compilers are +// permitted to, and often do, arbitrarily miscompile them. BoringSSL thus aims +// to avoid undefined behavior. +// +// Implementation-defined behavior is left up to the compiler to define (or +// leave undefined). These are often platform-specific details, such as how big +// |int| is or how |uintN_t| is implemented. Programs that depend on +// implementation-defined behavior are not necessarily invalid, merely less +// portable. A compiler that provides some implementation-defined behavior is +// not permitted to miscompile code that depends on it. +// +// C allows a much wider range of platform behaviors than would be practical +// for us to support, so we make some assumptions on implementation-defined +// behavior. Platforms that violate those assumptions are not supported. This +// file aims to document and test these assumptions, so that platforms outside +// our scope are flagged. + template static void CheckRepresentation(T value) { SCOPED_TRACE(value);