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: Where does the C standard describe overflow of signedintegers?


> 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.



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