[FFmpeg-devel] [RFC] Sechole in gcc 3.3+ and 4.*

Michael Niedermayer michaelni
Sat Apr 12 12:45:21 CEST 2008


On Sat, Apr 12, 2008 at 12:18:41AM -0400, Dave Dodge wrote:
> On Mon, Apr 07, 2008 at 03:02:13PM +0200, Michael Niedermayer wrote:
> > If C meant this to be undefined they could have said so explicitly like they
> > do for >> and signed numbers.
> 
> They do, over in "Terms and Definitions" (section 3) where signed
> integer overflow is given as an explicit example of something that
> causes undefined behavior.

Ive used xpdf to search for "overflow" amongth other
things before assuming that the C spec does not say anything about it
being undefined.
xpdf does not find this text in section 3 if you search for "overflow"
Anyway, i dont feel too well about this just being vaguly mentioned in an
example even less so as other examples contradict it.
And the example does NOT say signed, it says "integer overflow" thus
it would apply to unsigned as well which we all agree is not behaving
that way.

more searching for overflow (acroread) leads to:
----
a = (((a + 32760) + b) + 5); 
due to the associativity and precedence of these operators. Thus, the result
of the sum (a + 32760) is next added to b, and that result is then added to 5
which results in the value assigned to a. On a machine in which overflows
produce an explicit trap and in which the range of values representable by
an int is [ 32768, +32767], the implementation cannot rewrite this expression
as a = ((a + b) + 32765);
since if the values for a and b were, respectively,  32754 and  15, the sum
a + b would produce a trap while the original expression would not; nor can
the expression be rewritten either as 
a = ((a + 32765) + b);
or 
a = (a + (b + 32765));
since the values for a and b might have been, respectively, 4 and  8 or  17
and 12. However, on a machine in which overflow silently generates some value
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
and where positive and negative overflows cancel, the above expression
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
statement can be rewritten by the implementation in any of the above ways
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
because the same result will occur.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
----

So IMO what the authors apparently wanted is to support machines where
signed overflow causes traps, thats fine and it makes sense. It does
not appear to me that they meant to allow the compiler to randomize
code which behaves perfectly correct on the acual hardware.

Also undefined overflow is nowhere mentioned except that example, it is
NOT amongth the list of undefined things.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080412/0e753747/attachment.pgp>



More information about the ffmpeg-devel mailing list