Where does the C standard describe overflow of signed integers?

[Georg Bauhaus]

Dave Korn wrote:

>>You can have both, correctness and uninitialised local
>>variables. For an impression of the difference in performance,
>>and for a way to ensure correctness, I tried this
>>(switch register/volatile in the declaration lines in comp
>>and r to see the effects).
>>    
>>
>
>  I didn't get that far.  Before the first call to comp the program has
>already accessed uninitialised memory:
>  
>
[...]

>>  for (size_t c=0; c < hi + 2; ++c) {
>>    if (a[c]) {
>>    
>>
>
>  Uninitialised variable access.  Boom.  *NOT* correct.
>  
>

Right, but not so much Boom because `a` is full of don't care
shorts. Rather because if x, y, and z are register variables
they might never be assigned; if a[c] happens to always yield 0,
then the function r adds uninitialised local variables in
   return x + y + z;
GCC tells us, anyway.

And then there is + 2 in the loop condition which
might move c off the end of a before a[c]. Another bug,
unrelated to uninitiliased variables.

If you remove the if (a[c]) entirely here and also the + 2
(left over when quickly scribbling a program),
then x, y, and z will be computed. I think the assert
statement has a lot more to say about correctness
than when the register variables get some (which?) initial
values that are not used ever.

>  In what sense of the word 'correct' do you claim this example is correct?
>  
>

The example was intended to demonstrate two things:

1) initialising variables doesn't necessarily make programs any
  more correct.
  Initialisation might be redundant, distracting, and inviting
  asymmetric expressions, see below.  A good initial value
  for some algorithm might depend on other values, hence it is
  known only after a conditional. Pseudo code:

  f(a, b):
     x <- some initial value
      # expr doesn't show init really depends on cond(a, b)
     ...
     if cond(a, b):
        x <- a different initial value  # asymmetry here
        compute(x, ...)
     else:
        compute(x, ...)

2) if putting local variables in registers becomes impossible
  there will be a significant cost. I wanted to get an impression
  of the cost. That's the reason for writing volatile in the
  declaration lines. Just for demo.)


-- Georg