Re: fun with ?:

[Derek M Jones <derek@knosof.co.uk>]

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@knosof.co.uk
Applications Standards Conformance Testing    http://www.knosof.co.uk