https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69550
--- Comment #15 from Martin Sebor <msebor at gcc dot gnu.org> --- I did try to match the C front end but there are a few cases where I made C++ slightly stricter based on Jason's input about the direction C++ is heading with respect to aliasing rules. This is one of those cases (there's a test for it in the test suite). In addition, besides maintaining the property that every complete type has a non-zero size, the C rationale for requiring structs containing a flexible array to have at least one other member is to store the size of the array alongside it. As for the request to relax the stricter C++ rules with -fpermissive, while I defer to Jason and others, my inclination is not to unless it turns out that the use case of having just a zero-length array and a flexible array as the sole members is a common idiom. Regarding the test case in the attachment, I'm not sure I understand the purpose of having two arrays that are essentially equivalent. Flexible array members were introduced into the language as a replacement of zero-length arrays (to avoid what's known as the struct hack). But if having two such arrays is nececcary for some reason, changing the flexible array member to a zero-length array should get around the error in an ABI/API compatible way.
