Linus,
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.
It is an example of order of evaluation mattering when overflow
occurs.
No it isn't.
It was intended as a probabilit statement (ok, I did not make that
clear). An expression containing n+n is more likely to overflow
than one containing n-n.
Anyway, getting away from nit-picking of what was intended to be a throw
away remark.
"1 + n - n" can overflow equally as "1 + n + n - n -n" can, and if you
want them to do saturation or something, you cannot optimize _either_ of
them to just "1". If "n" is MAX_INT, then with saturating arithmetic,
neither of them results in 1.
Saturated arithmetic kills off so many optimizations because reordering
an expression might produce different results.
Not that signed overflow is even specified by the C standard (and
unsigned is specified to be well-behaved).
Overflow for signed integer types is undefined behavior
(well technically this is an instance of
"... not in the range of representable values for its type",
sentence 490 http://c0x.coding-guidelines.com/6.5.html).
So it seems to be purely a compiler misfeature. No excuses.
This is the point of the discussion that has got me confused.
What compiler misfeature? Perhaps I am using the 'wrong' version
of gcc (version 4.0.2), but I get the expected wrapping behavior (ie,
the compiler tries to behave at translate time the same way as st
runtime).
--
Derek M. Jones tel: +44 (0) 1252 520 667
Knowledge Software Ltd mailto:derek@xxxxxxxxxxxx
Applications Standards Conformance Testing http://www.knosof.co.uk
-
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
