On Wed, May 23, 2007 at 11:47:16PM +0900, Neil Booth wrote:
> > gcc integer constant expressions handling is a bad joke.
> >
> > extern int n;
> > struct {
> > int x : 1 + n - n;
> > } y;
> >
> > passes with -pedantic -std=c99. Replacing that with 1 + n - n + n - n
> > is still OK with gcc; 1 + n + n - n - n is not.
> >
> > So that's hardly an example of, well, anything.
>
> Consistency? :-) I wasn't aware of the quirk of the second example.
>
> Apparently these expressions are only folded if their net result
> is obvious as parsed by the grammar. Fixing this in GCC is a
> horrendous amount of work; so much internal logic relies on this
> early simplification, which is why it's not been done I guess.
With sparse that's easier - we have parsing and typechecking separated
enough. And yes, blind evaluate + expand will suffer similar problems.
However, it's not hard to have evaluate_expression() to set a flag
when it steps into a construct prohibited in integer constant expressions.
BTW, immediate cast from float is not hard - you need all casts other than
under sizeof go to integer type *and* you need any operations involving
floating point types to set "not an integer constant expression". Since
comma and function calls are also banned, float will either go all
way up or it will be eaten by cast.
BTW, the fun question is whether (int)(1.1) is allowed; the same goes
for "is ((void *)0) a null pointer constant". 6.5.1 is sloppy ;-)
-
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
