Some code [0] consider that trailing arrays are flexible, whatever their size.
Support for these legacy code has been introduced in
f8f6324983 but it prevents evaluation of
__builtin_object_size and __builtin_dynamic_object_size in some legit cases.
Introduce -fstrict-flex-arrays=<n> to have stricter conformance when it is
desirable.
n = 0: current behavior, any trailing array member is a flexible array. The default.
n = 1: any trailing array member of undefined, 0 or 1 size is a flexible array member
n = 2: any trailing array member of undefined or 0 size is a flexible array member
This takes into account two specificities of clang: array bounds as macro id
disqualify FAM, as well as non standard layout.
Similar patch for gcc discuss here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
[0] https://docs.freebsd.org/en/books/developers-handbook/sockets/#sockets-essential-functions
...that had temporarily regressed with (since reverted)
<886715af96>
"[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
serge-sans-paille