public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Paul Schlie <schlie@comcast.net>
To: Robert Dewar <dewar@adacore.com>
Cc: GCC Development <gcc@gcc.gnu.org>
Subject: Re: Where does the C standard describe overflow of signed integers?
Date: Thu, 14 Jul 2005 05:28:00 -0000	[thread overview]
Message-ID: <BEFB7021.ACF7%schlie@comcast.net> (raw)
In-Reply-To: <42D5C70F.5060109@adacore.com>

> From: Robert Dewar <dewar@adacore.com>
>> Paul Schlie wrote:
>> Although I don't intend to extend the debate; doesn't anyone find it curious
>> that given this hard requirement, combined with the fact that all current
>> machine architectures rely on 2's complement signed integer representation
>> to eliminate the otherwise necessity for distinct signed integer arithmetic
>> operations; that by extension unsigned and signed integer arithmetic
>> operations are behaviorally equivalent all current machine implementations
>> (as well as likely future implementations for the same reasons);
> 
> nonsense!  -1/1 = 0 signed, -1 unsigned

Actually as -1(signed) == UINT_MAX(unsigned) there's no problem, as
1..1/0..1 == 1..1.  Although suspect you meant something like 1/-1. However
as 2's complement division typically presumes the effective conversion of
signed values to their absolute unsigned values (which is the form in which
the division typically takes place, which is itself often further decomposed
to conditional modulo unsigned subtractions, and then sign corrected
afterward), I don't view this as a discrepancy; but do agree signed division
is typically a distinct operation, which wraps sign correction around a
fundamentally unsigned division operation; which itself tends to rely on
modulo unsigned subtraction at it's core.

> -1 < 1 signed, -1>1 unsigned

Agreed, however as above, comparison operations are essentially composed of
an unsigned modulo subtraction, who's result's high order virtual sign bit
determines the logical result of the operation as a function of the xor of
it's operand's virtual sign bits. So essentially again just an wrapper over
an unsigned modulo subtraction operation.

1..1 - 0..1 == 1..0 => true (signed), false (unsigned)

So overall, it seems pretty clear that even these two arguable exceptions
actually themselves tend to rely on modulo unsigned arithmetic at their core
in all typical implementations of these signed operations.


  reply	other threads:[~2005-07-14  5:28 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-14  1:10 Paul Schlie
2005-07-14  1:59 ` Robert Dewar
2005-07-14  5:28   ` Paul Schlie [this message]
2005-07-14 17:57 ` Matthew Woodcraft
2005-07-14 18:36   ` Paul Koning
  -- strict thread matches above, loose matches on Subject: below --
2005-07-14 19:09 Paul Schlie
2005-07-14 19:13 ` Robert Dewar
2005-07-14 19:28   ` Paul Schlie
2005-07-14 19:33     ` Robert Dewar
2005-07-14 20:13       ` Paul Schlie
2005-07-15 13:20         ` Georg Bauhaus
2005-07-15 13:33           ` Georg Bauhaus
2005-07-15 14:31           ` Dave Korn
2005-07-16 12:04             ` Georg Bauhaus
2005-07-16 14:26               ` Paul Schlie
2005-07-15 15:03           ` Paul Schlie
2005-07-16 12:12             ` Georg Bauhaus
2005-07-14 20:35     ` Paul Koning
2005-07-14 21:58       ` Paul Schlie
2005-07-15  7:04         ` Avi Kivity
2005-07-11 14:58 Nicholas Nethercote
2005-07-11 15:07 ` Dave Korn
2005-07-11 16:07   ` Nicholas Nethercote
2005-07-11 17:04     ` Dave Korn
2005-07-11 15:15 ` Nathan Sidwell
2005-07-11 15:23   ` Dave Korn
2005-07-12 23:13 ` Michael Meissner

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=BEFB7021.ACF7%schlie@comcast.net \
    --to=schlie@comcast.net \
    --cc=dewar@adacore.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).