public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Paul Schlie <schlie@comcast.net>
To: Joe Buck <Joe.Buck@synopsys.COM>,
	Gabriel Dos Reis <gdr@integrable-solutions.net>
Cc: <gcc@gcc.gnu.org>
Subject: Re: Should GCC publish a general rule/warning due to it's default presumption of undefined signed integer overflow semantics?
Date: Fri, 01 Jul 2005 01:04:00 -0000	[thread overview]
Message-ID: <BEEA0EB8.AAF4%schlie@comcast.net> (raw)
In-Reply-To: <20050630232531.GA11010@synopsys.com>

> Joe Buck <Joe.Buck@synopsys.COM>
> Undefined behavior doesn't mean that we should attempt to arbitrarily
> punish those who cross the line; that's why I don't think forcing integer
> overflows to trap (at least by default) is a good idea.  In many cases,
> "assume no overflow, but don't trap" can produce a better result than
> "assume wrap" does, as in the example I gave before.

My primary concern is about predictability, and could live with undefined
integer overflow if it were likely reasonably possible to verify that in
the general case an overflow would not occur, as otherwise an undefined
behavior may result. (which I can't believe is acceptable to anyone).

Although I recognize and accept that most trivial uses of signed arithmetic
can likely be verified as being constrained or not; it seems pretty clear
to me that it's very difficult and often strictly impossible in the general
case to do so; implying that signed integer arithmetic needs to be avoided
in the general case by either specifying signed integers as being unsigned
and convert them as required post-fact (which may also be undefined), and/or
utilize floats if one wants to produce a program which has a reasonable
chance of predictable behavior.

(My question was an honest one, although candidly somewhat pointed; as prior
to recent discussions it wasn't clear to me how potentially serious an issue
this was; so thought being forewarned was better than being surprised by
unexpected behaviors which may only express themselves in subtle non-obvious
circumstances.)


  parent reply	other threads:[~2005-07-01  1:04 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-30 19:15 Paul Schlie
2005-06-30 20:08 ` Paul Schlie
2005-06-30 22:06 ` Joe Buck
2005-06-30 22:26   ` Gabriel Dos Reis
2005-06-30 23:25     ` Joe Buck
2005-07-01  0:49       ` Gabriel Dos Reis
2005-07-01  1:03         ` Andrew Pinski
2005-07-01  1:23           ` Gabriel Dos Reis
2005-07-01  1:25           ` Joe Buck
2005-07-01  1:40             ` Gabriel Dos Reis
2005-07-01  3:16               ` Daniel Berlin
2005-07-01  4:07                 ` Gabriel Dos Reis
2005-07-01  4:15                   ` Andrew Pinski
2005-07-01  4:58                     ` Gabriel Dos Reis
2005-07-01  4:53                       ` Andrew Pinski
2005-07-01  5:02                         ` Gabriel Dos Reis
2005-07-02 16:51                   ` Robert Dewar
2005-07-02 19:07                     ` Gabriel Dos Reis
2005-07-02 23:15                       ` Robert Dewar
2005-07-02 23:28                         ` Joe Buck
2005-07-03  0:20                           ` Gabriel Dos Reis
2005-07-03  0:16                         ` Gabriel Dos Reis
2005-07-02 16:47           ` Robert Dewar
2005-07-02 16:45         ` Robert Dewar
2005-07-01  1:04       ` Paul Schlie [this message]
2005-07-02 16:48         ` Robert Dewar
2005-07-01  1:35       ` Paul Schlie

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=BEEA0EB8.AAF4%schlie@comcast.net \
    --to=schlie@comcast.net \
    --cc=Joe.Buck@synopsys.COM \
    --cc=gcc@gcc.gnu.org \
    --cc=gdr@integrable-solutions.net \
    /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).