Integer overflow and underflow semantics?
via Digitalmars-d
digitalmars-d at puremagic.com
Tue Jul 22 23:50:52 PDT 2014
On Tuesday, 22 July 2014 at 21:06:09 UTC, Artur Skawina via
Digitalmars-d wrote:
> D is defined as it is, with wrapping two's complement integer
> arithmetic
> and defined integer sizes.
Integer promotion is locked to 32 bits. That is a mistake. Why
wrap everything below 32bit at 32 on a 64 bit ALU? That's
inconvinient and will lead to undetected bugs.
I also think it is a mistake to lock to C rules, which were
defined when multiply often were done in software. In most modern
ALUs a N bit multiply yields a 2*N bit result. Why discard the
high word?
With forced wrapping/masking (a*b)>>32 is turned into
((a*b)&0xffffffff)>>32 which is zero, so you have to cast 'a' to
64 bit before the multiply, then downcast the result to 32 bit.
> My point is that the language must be consistent; adding special
> cases would create a language in which one expression yields
> several
> different results, depending on evaluation context.
I understand this point, but I think code that would yield such
errors most lkely is buggy or underspecified.
Ola.
More information about the Digitalmars-d
mailing list