Al Viro wrote:
> Current tree handling of initializers is rather incomplete
> and in many cases broken. Patchset rewrites that stuff pretty much
> from scratch; AFAICS it works.
Patchset applied; thanks!
The validation output changed slightly:
-validation/initializer-entry-defined-twice.c:10:12: error: Initializer entry defined twice
-validation/initializer-entry-defined-twice.c:11:12: also defined here
-validation/initializer-entry-defined-twice.c:25:7: error: Initializer entry defined twice
-validation/initializer-entry-defined-twice.c:27:8: also defined here
+validation/initializer-entry-defined-twice.c:10:3: error: Initializer entry defined twice
+validation/initializer-entry-defined-twice.c:11:3: also defined here
+validation/initializer-entry-defined-twice.c:26:4: error: Initializer entry defined twice
+validation/initializer-entry-defined-twice.c:27:4: also defined here
Given that this just affected the column numbers, and sparse still reports the
correct line numbers, I didn't worry about it.
> * fixed handling of gccisms (unnamed union as a member, empty struct
> as a member) to match gcc behaviour; gcc extension allowing ("a") to be
> treated as "a" is handled, with a warning conditional on -Wparen-string
> (default is off). BTW, several places in the kernel have that sort of
> idiocy.
How much spew does -Wparen-string cause? If you feel that it always
represents an error, or at least sloppy code, and that it won't drown people
in warnings, I have no problem with turning it on by default. Your call.
> Areas still missing:
[...]
> * calculation of array size by initializer is still broken; at least
> now we get warnings about missing braces in the cases that trigger that
> crap; struct {int a, b;} a[] = {1,2,3,4,5}; should give a 3-element array,
> not 5-element one. New code warns about missing braces and puts the values
> in right places, but it still doesn't fix the array size calculation - it's
> done too early. Since evaluate_initializer() can work with array of
> unknown size, perhaps the best solution would be to call it from the
> count_array_initializer() and look for maximal index in the results if
> we have EXPR_INITIALIZER / look for string size otherwise (no other
> variants are possible for arrays). Objections?
That seems like a great approach to me; logically, an initializer should
expand an array of unspecified size to hold elements up to its maximum index.
Hopefully this would also fix the problem reported by Michael Stefaniuc in
<466489FD.7010405@xxxxxxxxxx>:
> Running sparse on
> int i = sizeof((const char []) {'a','a','a',0});
> gives
> zzz.c:1:9: error: cannot size expression
- Josh Triplett
Attachment:
signature.asc
Description: OpenPGP digital signature
