Open GustavoARSilva opened 2 years ago
It seems like overlapping with a matching type is okay (in the sense that an implicit union has been created). I wonder if the non-matching type throws an error with the compiler? It's not clear to me if either case should be considered a problem...
It seems like overlapping with a matching type is okay (in the sense that an implicit union has been created). I wonder if the non-matching type throws an error with the compiler? It's not clear to me if either case should be considered a problem...
Yep; I'll look into that. :)
NOTE (2024-04-19 - present):
I'm currently actively working on this issue.
If you want to help us with KSPP tasks, please take a look at a different issue while this note is up. :)
Thank you!
Fix all
-Wflex-array-member-not-at-end
warningsWhen a struct containing a flexible array is included in another struct, sometimes an implicit union is created if there is a member after the struct-with-flex-array; see:
We need to audit all the places where this occurs and determine if the fact that instance->header.flex[0] and instance->overlap share the same memory location is intentional or if this is a legit bug.
Below is a Cocci script that can be used to spot these instances. Notice that it also identifies the case of one-element arrays. In this case, the behavior is slightly different in that the address of that type of array will not be the same as the address of the next member in the outer structure. However, if this array is actually being treated as a flexible array at run-time it might cause problems and it's worth auditing those instances, too.
the script above identifies instances where both fake (one-element and zero-length arrays) and true (C99 flexible-array member) flexible arrays are used.
Here are all the instances the script above currently identifies in next-20220920: