[PATCH] D134902: [clang] Implement -fstrict-flex-arrays=3
Aaron Ballman via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Tue Oct 25 05:48:19 PDT 2022
aaron.ballman added a comment.
In D134902#3848616 <https://reviews.llvm.org/D134902#3848616>, @kees wrote:
> In D134902#3848595 <https://reviews.llvm.org/D134902#3848595>, @serge-sans-paille wrote:
>
>> I second the opinion here. C99 says nothing about flexible array member for unions, that's already a "language extension". (and so not be considered as FAM by `-fstrict-flex-arrays=3`)
>
> To be super pedantic, C99 implies a FAM in a union is illegal. 6.7.2.1.16 says "As a special case, the last element of a structure with more than one named member may have an incomplete array type; this is called a flexible array member." The implication is that such a state ("more than one named member") isn't possible in a union.
The C standard says "structure" when it means `struct` and "union" when it means `union`, and "structure and/or union" when it means both/either, so this constraint is not implied -- it's explicitly stated. A FAM in a union is a constraint violation per 6.7.2.1. (Note: C compilers are not consistent about getting this constraint correct. Clang and GCC both get it right, ICC, MSVC, SDCC all get it wrong.)
> But in real-world usage, this definition isn't useful and flies in the face of actual (fake) FAM usage. Having fake FAMs in unions is _very_ common in the Linux kernel, and they even appear alone in structs. There is no pragmatic reason for the C99 limitation, and it's needlessly enforced only for "real" FAMs. But this is a separate issue we can solve separately.
A *fake* FAM is undefined behavior and thus fair game for implementations to define the behavior of in whatever way we'd like, so long as developers know it's not portable and it may explode on other compilers. A real FAM requires at least a diagnostic, but we're free to make it a pedantic warning diagnostic if we want. If we feel strongly about the limitation being needless, we could propose to standardize support for it if implementations that accept a real FAM in a union basically all agree on the behavior. (Agreed that this is a separate issue from this patch though.)
One thing I would appreciate is, once we're getting close to done with the work around flexible arrays, is to explicitly document our implementation-defined behaviors around flexible arrays in https://clang.llvm.org/docs/LanguageExtensions.html. Right now, what is and isn't a flexible array to Clang is really complex and not having the rules written down anywhere is not helpful to users. These cleanup efforts are fantastic and seem like a good opportunity for us to rectify the lack of docs.
================
Comment at: clang/docs/ReleaseNotes.rst:386
+- Added a new level to the ``-fstrict-flex-arrays=`` flag. The new level ``3``
+ recoginizes only "incomplete" arrays as flexible array members.
+
----------------
I think another way to phrase this is that level `3` only supports flexible array members as the feature is defined by the C standard, aka, this is standards-conforming mode. WDYT?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D134902/new/
https://reviews.llvm.org/D134902
More information about the cfe-commits
mailing list