Hi, Joseph,
> On Feb 6, 2023, at 6:14 PM, Joseph Myers <jos...@codesourcery.com> wrote: > > On Mon, 6 Feb 2023, Qing Zhao via Gcc-patches wrote: > >> In GCC14: >> >> 1. Include this new warning -Wgnu-varaible-sized-type-not-at-end to -Wall >> 2. Deprecate this extension from GCC. (Or delay this to next release?). > > Any deprecation, or inclusion in -Wall, would best come with evidence > about the prevalance of use (possibly unintentional, probably undesirable) > of these extensions. For example, maybe someone could do a distribution > rebuild with a patch to enable these warnings and report the results? Yes, before we deprecate this extension, it’s better to make sure all such misuses are updated already. > > Various misuses of flexible array members are only pedwarns-if-pedantic > because of such uses - and while the original motivating case > <https://gcc.gnu.org/legacy-ml/gcc-patches/2002-08/msg01149.html> Just checked this patch (which has been in GCC source tree already), the routine flexible_array_type_p +/* Determine whether TYPE is a structure with a flexible array member, + or a union containing such a structure (possibly recursively). */ + +static bool +flexible_array_type_p (type) Did not include the following cases: 1. Structure with flexible array member embedded into other structures recursively, for example: struct A { int n; char data[]; }; struct B { int m; struct A a; }; struct C { int q; struct B b; }; In the above, “struct C” will not be caught by this routine. Shall “struct C” be included? 2. Only C99 standard flexible array member be included, [0] and [1] are not included, for example: struct A { int n; char data[0]; }; struct B { int m; struct A a; }; struct C { int q; struct B b; }; In the above, “struct B” and “struct C” will not be caught by this routine. Shall “the above struct B” and “struct C” be included per -fstrict-flex-arrays? Could you please take a look at my latest patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611445.html To see whether the new bit “TYPE_INCLUDE_FLEXARRAY” covers the above “flexible_array_type_p”? Then we can merge them together? > was > _G_config.h, which has since been fixed (though existing installed headers > from old glibc would need fixincluding, at least if it becomes an error), > it's very plausible there are uses of these extensions elsewhere. If this is the case, we should definitely deprecate this extension. Thanks. Qing > > -- > Joseph S. Myers > jos...@codesourcery.com
