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

[Dave Dodge]

On Sat, Apr 12, 2008 at 12:45:21PM +0200, Michael Niedermayer wrote:
> 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

I see what you mean about xpdf.  For some reason evince does find it
in the same file (I'm looking at n1124).  There are other cases where
evince doesn't find phrases that are clearly part of the text.

> Anyway, i dont feel too well about this just being vaguly mentioned
> in an example even less so as other examples contradict it.

True enough; examples (like footnotes) aren't considered normative
anyway.

> 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.

Looking closer, the Standard is a bit loose about how it uses the term
"overflow".  Going by the normative text (particularly 6.2.5 p9) it
seems that any discussion of integer overflow must apply only to
signed integers, because it says explicitly that unsigned computations
"can never overflow".  Unsigned overflow doesn't seem to be a valid
concept from the Standard's point of view; instead it talks about how
unrepresentable unsigned values are "reduced" to be in range.

Now later on in Annex H it does appear to mention overflow in the
context of unsigned values, but that annex is non-normative.

> 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.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Again non-normative, but I agree the wording here is interesting.

> So IMO what the authors apparently wanted is to support machines where
> signed overflow causes traps, thats fine and it makes sense.

Agreed.

> It does not appear to me that they meant to allow the compiler to
> randomize code which behaves perfectly correct on the acual
> hardware.

Another way to look at the ordering requirement in the above example
is that it could be intended to prevent the compiler from rewriting
expressions such that an overflow condition is _created_, where none
would have existed if evaluation were done in the original order.

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

There's a catch-all in section 4:

  Undefined behavior is otherwise indicated in this International
  Standard by the words "undefined behavior" or by the omission of any
                                             ^^^^^^^^^^^^^^^^^^^^^^^^^
  explicit definition of behavior.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Also, they clearly intended to allow signed overflow to generate a
trap on some architectures, and there's very little in the way of
constraints on what traps might do.  It was probably easier to leave
it undefined than try to think up all the ways an architecture might
reasonably react -- aborting execution, wrapping the value, sending a
signal, capping the value at INT_MAX, etc.

                                                  -Dave Dodge