On Tue, 25 Feb 2003, Andreas Schwab wrote:
> |>
> |> So? Gcc does that anyway. _Any_ good compiler has to.
>
> But the point is that determining the common type does not require _any_
> kind of data flow analysis, and this is the place where the unsigned
> warning is generated.
Go back and read my mail. In fact, go back and read just about _any_ of my
mails on the subject. Gop back and read the part you snipped:
"And if the compiler isn't good enough to do it, then the compiler
shouldn't be warning about something that it hasn't got a clue about."
In other words, either gcc should do it right, or it should not be done at
all. Right now the warning IS GENERATED IN THE WRONG PLACE. Your argument
seems to be "but that's the place it is generated" is a total
non-argument. It's just stating a fact, and it's exactly that fact that
causes the BUG IN GCC.
> |> Trivial example:
> |>
> |> int x[2][2];
> |>
> |> int main(int argc, char **argv)
> |> {
> |> return x[1][-1];
> |> }
> |>
> |>
> |> the above is actually a well-defined C program, and 100%
> |> standards-conforming ("strictly conforming").
>
> This isn't as trivial as it seems. Look in comp.std.c for recent
> discussions on this topic (out-of-array references).
It is as trivial as it seems, and this is _not_ an out-of-array reference.
Sorry. C very clearly specifies the layout of arrays (6.5.2.1: last
subscript varies fastest, together with sizeof(array) = sizeof(entry)*n),
which _guarantees_ that the pointers involved in the above calculations
are all within the object, and thus there is _zero_ undefined behaviour.
So if they argued about this on comp.std.c, they either had clueless
people there (in addition to the ones that obviously aren't ;), _or_ you
misunderstood the argument.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Feb 28 2003 - 22:00:28 EST