Re: The utility of standard's semantics for overflow

[Michael Veksler <VEKSLER at il dot ibm dot com>]

Eric Botcazou <ebotcazou@libertysurf.fr> wrote on 29/06/2005 11:49:24:

> > This is unlike aliasing, when most lines of code out there,
> > did not break aliasing rules (even before they were
> > introduced).
>
> Are you sure?  IIRC -fstrict-aliasing was once enabled at -O2 and then
> disabled to give people more time to fix their code.
>

Yes, I am pretty sure. I said "most lines of code", not "most
applications",
to indicate the density difference. If each line of code has, e.g., 1%
chance
to violate overflow rules, and 0.01% chance to violate aliasing rules,
then for 10KLOC, you have:
 - probability of 63%   to violate aliasing rules
 - and 100% (99.99....9  with 43 nines) to violate overflow rules.

So most chances an a small application you will have at least
one violation for each rule. However, the number of violation will
be substantially different between the two:

The mean for number of violations for 10KLOC is:
- aliasing: 1
- overflow: 100

The numbers on probabilities are concocted, but they give the
general feeling of what I meant.
Aliasing problems may happen only when either:
1. Using type casts of pointers.
2. In C: implicit void* conversions.
3. Implicit pointer conversions through union.

These are less common (LOC percentage) in most code than
  i++, or a+b
Algorithm inputs are rarely validated for potential future overflow,
but outputs are normally validated for sane results. If you are
not supposed to produce a negative result, you are going to
catch it no later than at the beginning of your next stage
(assuming you have at least some sanity checks).


One more note: Programming languages should not only be sound,
they should fulfill a wide range of needs of the development cycle.
One of the needs is the ease of writing correct code and verifying it.
By defining a language rule that makes C/C++ very fast at the cost
of x2 more bugs is an unacceptable design decision. Most of these
new bugs will be latent bugs, and users will normally not encounter
them, but they will be there waiting for new bad inputs and an
improved compiler inteligence.


   Michael