Steven Schveighoffer:

> If we treated it as an error, then it would be very costly to implement, every operation would have to check for overflow.

I have used similar tests and it's not very costly, not significantly more costly than array bound tests.

In the meantime Clang has introduced similar run-time tests for C/C++ code. So C/C++ are now better (more modern, safer) than the D language/official compiler in this regard.

(And Issue 4835 is about compile-time constants. CFFE is already plenty slow, mostly because of memory allocations. Detecting overflow in constants is not going to significantly slow down compilation, and it has no effect on the runtime. Even GCC 4.3.4 performs such compile-time tests.)


> The CPU does not assist in this.

The X86 CPUs have overflow and carry flags that help.

Bye,
bearophile

On Tue, 26 Mar 2013 14:17:16 -0400, Luís Marques <luismarques@gmail.com> wrote:

> But my point is even more simple: is there a stance on what the overflow/underflow semantics are? E.g., are they undefined (might wrap, might saturate, might have one's complement behavior, etc), defined only for unsigned integers (like C and C++), etc?

http://dlang.org/expression.html#AddExpression

"If both operands are of integral types and an overflow or underflow occurs in the computation, wrapping will happen. That is, uint.max + 1 == uint.min and uint.min - 1 == uint.max."

-Steve

Am Tue, 26 Mar 2013 14:04:25 -0400
schrieb "Steven Schveighoffer" <schveiguy@yahoo.com>:

> 
> The official stance is, it's not an error.  If we treated it as an error, then it would be very costly to implement, every operation would have to check for overflow.  The CPU does not assist in this.

I think this is way more annoying though if the overflow happens in constant folding such as in the original example. In that case checking "only" adds overhead at compile time, so a warning would be nice.

On Tue, 26 Mar 2013 14:20:30 -0400, bearophile <bearophileHUGS@lycos.com> wrote:

> Steven Schveighoffer:
>
>> If we treated it as an error, then it would be very costly to implement, every operation would have to check for overflow.
>
> I have used similar tests and it's not very costly, not significantly more costly than array bound tests.

Array bounds tests are removed for release code.  And an array bounds test is unequivocally an error.

In many cases, overflowing integers are not a problem, easily proven not to occur, or are expected.  Such designs would have to fight the compiler to get efficient code if the compiler insisted on checking overflows and possibly throwing errors.

>
> In the meantime Clang has introduced similar run-time tests for C/C++ code. So C/C++ are now better (more modern, safer) than the D language/official compiler in this regard.
>
> (And Issue 4835 is about compile-time constants. CFFE is already plenty slow, mostly because of memory allocations. Detecting overflow in constants is not going to significantly slow down compilation, and it has no effect on the runtime. Even GCC 4.3.4 performs such compile-time tests.)

If CTFE did something different than real code, that would be a problem.  Again, you should be able to construct the needed types with a struct, to use in both CTFE and real code.

>
>> The CPU does not assist in this.
>
> The X86 CPUs have overflow and carry flags that help.

What I mean is the cost is not free.  Like null pointer checks are free.

For code that is specifically designed to be very fast and is properly designed not to experience overflow, it would be needlessly penalized.

The simple for loop:

for(int i = 0; i < 10; ++i)

would now have to deal with uselessly checking i for overflow.  This could add up quickly.

-Steve

>> (And Issue 4835 is about compile-time constants. CFFE is already plenty slow, mostly because of memory allocations. Detecting overflow in constants is not going to significantly slow down compilation, and it has no effect on the runtime. Even GCC 4.3.4 performs such compile-time tests.)
>
> If CTFE did something different than real code, that would be a problem.  Again, you should be able to construct the needed types with a struct, to use in both CTFE and real code.

Let me clarify that constants that are combined by default (even without optimizations enabled), like the OP's example of 1024 * 1024 * 1024, should be able to emit an error at compile time on overflow, or automatically upgrade the type, I agree with that.

-Steve

On Tue, 26 Mar 2013 14:30:21 -0400, Johannes Pfau <nospam@example.com> wrote:

> Am Tue, 26 Mar 2013 14:04:25 -0400
> schrieb "Steven Schveighoffer" <schveiguy@yahoo.com>:
>
>>
>> The official stance is, it's not an error.  If we treated it as an
>> error, then it would be very costly to implement, every operation
>> would have to check for overflow.  The CPU does not assist in this.
>
> I think this is way more annoying though if the overflow happens in
> constant folding such as in the original example. In that case checking
> "only" adds overhead at compile time, so a warning would be nice.

Yes, I agree there.  The OP's code should either error out, or auto-promote to long.

But not in the general case.

-Steve

On Tuesday, 26 March 2013 at 18:24:39 UTC, Steven Schveighoffer wrote:
> http://dlang.org/expression.html#AddExpression
>
> "If both operands are of integral types and an overflow or underflow occurs in the computation, wrapping will happen. That is, uint.max + 1 == uint.min and uint.min - 1 == uint.max."

Thanks Steve!

Do you know if there ever was a (public?) discussion about this, before being defined this way? I wanted to see what trade-offs were considered, etc.

(For instance, one disadvantage I see with this definition is that it exacerbates the potential problems with D's well-defined integral types' sizes. Imagine I'm programming some microcontroller with unusual word or register sizes. For instance, 10 bits bytes instead of the usual 8 bit bytes. In C there would not be any performance penalty even for the unsigned char, which mandates wrapping, because the wrapping would occur at 2^10. In D you would have to put extra checks because a well defined size plus a well defined wrapping would not allow just using the native arithmetic instructions alone, which presumably would not guarantee wrapping at 8-bit widths.)

On 3/26/13 1:56 PM, "Luís Marques" <luismarques@gmail.com>" wrote:
> BTW, as far as I can see the overflow/underflow behavior never got
> specified by the language, in any case:
>
> 1) http://forum.dlang.org/thread/jo2c0a$31hh$1@digitalmars.com <-- no
> conclusion
>
> 2) Andrei's book doesn't seem to mention the topic.
>
> If it is specified somewhere please do tell. Whatever the behavior
> should be (unspecified, modulus for unsigned integers, etc) there really
> should be an official stance.

D obeys two's complement overflow rules for its signed and unsigned arithmetic. TDPL defines a checked integer type as an example of operator overloading.

Andrei

On Tuesday, 26 March 2013 at 18:48:27 UTC, Andrei Alexandrescu wrote:
> D obeys two's complement overflow rules for its signed and unsigned arithmetic. TDPL defines a checked integer type as an example of operator overloading.

I guess my searches for "overflow", "underflow", "modulus", etc missed that :-)

BTW, Andrei, what do you think the impact of this is for embedded systems with unusual word lengths (combined with D's well-defined type sizes)?

On 3/26/13 2:53 PM, "Luís Marques" <luismarques@gmail.com>" wrote:
> BTW, Andrei, what do you think the impact of this is for embedded
> systems with unusual word lengths (combined with D's well-defined type
> sizes)?

I think we're a bit biased toward x86, but I also think C's cavalier approach to data sizes and operational semantics ain't better.

Andrei