public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Theodore Papadopoulo <Theodore.Papadopoulo@sophia.inria.fr>
To: Michael Veksler <VEKSLER@il.ibm.com>
Cc: gcc@gcc.gnu.org
Subject: Re: The utility of standard's semantics for overflow
Date: Wed, 29 Jun 2005 09:47:00 -0000	[thread overview]
Message-ID: <1120038177.23191.36.camel@mururoa> (raw)
In-Reply-To: <OFD3D9025B.5DBCC2A3-ON4325702F.002AE087-4325702F.002EEDDD@il.ibm.com>

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.

  parent reply	other threads:[~2005-06-29  9:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-29  8:33 Michael Veksler
2005-06-29  8:42 ` Robert Dewar
2005-06-29  9:04   ` Michael Veksler
2005-06-29  9:18     ` Robert Dewar
2005-06-29  8:48 ` Eric Botcazou
2005-06-29 11:16   ` Michael Veksler
2005-06-29 16:19     ` Eric Botcazou
2005-06-29  9:47 ` Theodore Papadopoulo [this message]
2005-06-29 12:14   ` Robert Dewar
2005-06-29 13:12     ` Dave Korn
2005-06-29 13:35       ` Robert Dewar
2005-06-29 18:37       ` Olivier Galibert
2005-07-01 18:22         ` Alexandre Oliva
2005-07-01 18:30       ` Alexandre Oliva

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1120038177.23191.36.camel@mururoa \
    --to=theodore.papadopoulo@sophia.inria.fr \
    --cc=VEKSLER@il.ibm.com \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).