Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[test] Check for more -fsanitize=array-bounds behavior
...that had temporarily regressed with (since reverted) <886715a> "[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays", and had then been seen to cause issues in the wild: For one, the HarfBuzz project has various "fake" flexible array members of the form > Type arrayZ[HB_VAR_ARRAY]; in <https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-open-type.hh>, where HB_VAR_ARRAY is a macro defined as > #ifndef HB_VAR_ARRAY > #define HB_VAR_ARRAY 1 > #endif in <https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-machinery.hh>. For another, the Firebird project in <https://github.com/FirebirdSQL/firebird/blob/master/src/lock/lock_proto.h> uses a trailing member > srq lhb_hash[1]; // Hash table as a "fake" flexible array, but declared in a > struct lhb : public Firebird::MemoryHeader that is not a standard-layout class (because the Firebird::MemoryHeader base class also declares non-static data members). (The second case is specific to C++. Extend the test setup so that all the other tests are now run for both C and C++, just in case the behavior could ever start to diverge for those two languages.) A third case where -fsanitize=array-bounds differs from -Warray-bounds (and which is also specific to C++, but which doesn't appear to have been encountered in the wild) is when the "fake" flexible array member's size results from template argument substitution. Differential Revision: https://reviews.llvm.org/D128783
- Loading branch information