Integer overflow and underflow semantics?

[Iain Buclaw via Digitalmars-d]

On 22 July 2014 12:40, Artur Skawina via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 07/22/14 08:15, Iain Buclaw via Digitalmars-d wrote:
>> On 21 Jul 2014 22:10, "Artur Skawina via Digitalmars-d" <digitalmars-d at puremagic.com <mailto:digitalmars-d at puremagic.com>> wrote:
>>> For D that is not possible -- if an expression is valid at run-time
>>> then it should be valid at compile-time (and obviously yield the same
>>> value).
>>
>> ...most of the time.
>>
>> CTFE is allowed to do things at an arbitrary precision in mid-flight when evaluating an expression.
>
> That will work for FP, where excess precision is allowed, but will not work
> for integer arithmetic. Consider code which uses hashing and hash-folding
> functions which rely on wrapping arithmetic. If you increase the precision
> then those functions will yield different values. Now a hash value
> calculated at CT is invalid at RT...
>
> artur

I can still imagine a possibility of such occurring if cross-compiling
from a (doesn't exist) platform at does integer operations at 128bit
to x86, which at runtime is 64bit.

This is just brushing on the idea of a potential porting bug rather
than an actual problem.

Iain