This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: The utility of standard's semantics for overflow


On Wed, 2005-06-29 at 11:32 +0300, Michael Veksler wrote:

> This is unlike aliasing, when most lines of code out there,
> did not break aliasing rules (even before they were
> introduced). Int overflow is violated by most lines of
> code I have seen (it is very uncommon to find code that
> asserts no overflow before a+b).

Believe it or not most uses of integral values are made in such a way
that overflow is the exception rather than the rule (at least on general
computers where the int arithmetic and the memory is cheap, in embeded
system the situtation might differ somewhat even thought I have doubts
if the embedded processors are of 32b class, for 8/16b processor the
story is of course different). In most cases, the programmers choose the
type to allow for all the standard cases and do not look at the
possibility of overflow. How many loops are written using ints or
unsigned for very small integers where even a short might be
sufficient....

Untill now, there is a widespread assumption that 2^32 or 2^31 is
equivalent to infinity for most purposes, because those numbers will
never be reached (remember the unix clock ticks within a 32 bit
unsigned, which still has a few (counted) years to go) in any practical
situation (of course if a user wants to break the code and has switches
to provide initial values.

So unless you do arithmetics or combinatorics, most of the uses of
"wide" (ie > 32b) integral types semantically (ie in the programmer's
mind) assume that overflow does not happen in practise in the program.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]