On Fri, Sep 18, 2020 at 12:37:48PM -0700, Linus Torvalds wrote: > On Fri, Sep 18, 2020 at 12:28 PM Gustavo A. R. Silva > <gustavoars@xxxxxxxxxx> wrote: > > > > OK. It seems that we are talking about two different things here. One thing > > is to apply sizeof() to a structure that contains a flexible-array member. > > And the other thing is to apply sizeof() to a flexible array. The former > > is allowed, the latter is wrong and we already get a build error when that > > occurs. > > The latter I'm not even interested in, it's such a pointless thing to do. > > > Applying sizeof() to a structure containing a flex-array member is allowed, > > Yes, and that's wrong and inconsistent, but what else is new about the > C standard. It's what allows these kinds of bugs to slip through. > > I sent Luc a couple of examples in the hope that maybe sparse could do > better, but.. > > > > Is there some gcc option that I didn't find to help find any questionable cases? > > > > If the questionable case is the application of sizeof() to a flex-array > > member or a flex-array member not occuring last in the containing structure, > > then yes, GCC already generates a build error for both cases. And that's > > what we want, see at the bottom... > > No. > > The questionable thing is to do "sizeof(struct-with-flex-array)". I see now... > The point is, it's returning the same thing as if it was just a > zero-sized array, which makes the whole flex array entirely pointless > from a type safety standpoint. > > The *only* thing it protects against is the "must be at the end" case, > which is almost entirely pointless and uninteresting. > But you are missing the point about CONFIG_UBSAN_BOUNDS, which doesn't work with zero-lenght and one-element arrays. And we want to be able to use that configuration. That's the main reason why we are replacing those arrays with a flexible one. I should have made more emphasis on that point in my last response. Thanks -- Gustavo
