Hi, In HarfBuzz we extensively use the Struct Hack [0]. Up until now we've used "array[1]" for that. This upsets ubsan [1]. So I'm looking to replace it with flexible arrays on compilers that support it. However, trying to do that I get error if the flexible-array is the only member. Clang has no issues with it, but gcc gives me: "flexible array member '...' in an otherwise empty '...'". ``` struct UnsignedArray { int array[]; }; ``` I've seen: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69550 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71742 which suggests that disallowing flexible arrays in structs that have no other named member is intentional. But I cannot find the reason. Can someone please help me understand, and suggest a solution here? Note that if I use `int array[0]` instead, then gcc warns everytime in code we access that array with a constexpr value, like `array[0]` when we know it's safe to do. That is, gcc seems to treat `int array[0]` literally, not as a flexible array. Thank you. [0] http://c-faq.com/struct/structhack.html [1] https://github.com/harfbuzz/harfbuzz/issues/2953
I will let someone comment on the flexible array extension. But I will note GCC treats (all) arrays at the end of a POD struct as a flexible one so the question I have is more about the ubsan issue you are running into, is that with GCC or with clang/LLVM?
ISO C99 clearly says so: 6.7.2.1/16: "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 reason why G++ rejects structs with a flexible array as the sole member is because GCC (in C mode) doesn't accept them. Git log indicates that GCC started rejecting such code in r38705, which was committed as part of array member initialization cleanup. I don't know why the author of the change chose to reject such structs rather than accepting them with a warning, just like empty structs are accepted. If he had, C++ might have followed suit. At this point, I don't see GCC (in either mode) making a change unless C itself were to change first. That seems highly unlikely to me (the last proposal to relax the rules for flexible array members didn't go anywhere).
(In reply to Martin Sebor from comment #3) > The reason why G++ rejects structs with a flexible array as the sole member > is because GCC (in C mode) doesn't accept them. Git log indicates that GCC > started rejecting such code in r38705 Note this change was done long before clang was around so it would be interesting to know why clang chose differently.
G++ accepted structs where a flexible array is the sole member until version 6. G++ 6 tightened up the rules (in r231665) to more closely match the C front end. I suspect Clang implemented the more permissive historical G++ behavior in C++ mode for compatibility with G++ and the stricter GCC behavior in C mode, and to this day hasn't changed. My impression is that the historical G++ permissiveness was due to oversights rather than deliberate features (we're tracking a few such outstanding issues in pr69698 that are yet to be fixed).
Thank you all. I understand it's unlikely to happen at this point. In reply to Andrew Pinski from comment #1) > I will let someone comment on the flexible array extension. > > But I will note GCC treats (all) arrays at the end of a POD struct as a > flexible one so the question I have is more about the ubsan issue you are > running into, is that with GCC or with clang/LLVM? The ubsan issue reported to us is with gcc: https://github.com/harfbuzz/harfbuzz/issues/2953#issuecomment-823460893
(In reply to Behdad Esfahbod from comment #6) > > But I will note GCC treats (all) arrays at the end of a POD struct as a > > flexible one so the question I have is more about the ubsan issue you are > > running into, is that with GCC or with clang/LLVM? > > The ubsan issue reported to us is with gcc: > https://github.com/harfbuzz/harfbuzz/issues/2953#issuecomment-823460893 Can you report that as a bug as GCC's rule is treat all arrays that end a POD as a flexiable array? Please include the full preprocessed source that produces the problem at runtime and the specific version of GCC that is used. This is a GCC bug in mind due to this unless there is another field missing that is in the source that you are not showing.
(In reply to Andrew Pinski from comment #7) > > Can you report that as a bug as GCC's rule is treat all arrays that end a > POD as a flexiable array? Please include the full preprocessed source that > produces the problem at runtime and the specific version of GCC that is > used. This is a GCC bug in mind due to this unless there is another field > missing that is in the source that you are not showing. Thanks. Will do after reproducing.
Thus resolving as WONTFIX.