$cat test.cpp:

#include <iostream>

int main() {
	long long x = 1250000000 * 2;
	std::cout << x << std::endl;
	return 0;
}

g++-generated exe displays: -1794967296

$cat test.d:

import std.stdio;

int main() {
	long x = 1250000000 * 2;
	writefln("%d",x);
	return 0;
}

dmd- and gdc-generated exes display: -1794967296

compiling with g++ at least gives a warning:

warning: integer overflow in expression [-Woverflow]
long long x = 1250000000 * 2;

Both dmd and gdc do not complain in any way.

Isn't the promotion to int so awful? Better ideas? (yes, I know
about casting to long).

On Tue, 16 Jul 2013 12:37:58 +0200, eles <eles@eles.com> wrote:

> $cat test.cpp:
>
> #include <iostream>
>
> int main() {
> 	long long x = 1250000000 * 2;
> 	std::cout << x << std::endl;
> 	return 0;
> }
>
> g++-generated exe displays: -1794967296
>
> $cat test.d:
>
> import std.stdio;
>
> int main() {
> 	long x = 1250000000 * 2;
> 	writefln("%d",x);
> 	return 0;
> }
>
> dmd- and gdc-generated exes display: -1794967296
>
> compiling with g++ at least gives a warning:
>
> warning: integer overflow in expression [-Woverflow]
> long long x = 1250000000 * 2;
>
> Both dmd and gdc do not complain in any way.
>
> Isn't the promotion to int so awful? Better ideas? (yes, I know
> about casting to long).

This is where integer suffixes can help:

long x = 1250000000L * 2;

-- 
Simen

eles:

> Isn't the promotion to int so awful? Better ideas? (yes, I know
> about casting to long).

Bug report/ER:
http://d.puremagic.com/issues/show_bug.cgi?id=4835

There is a pull request, but it's currently stalled:
http://d.puremagic.com/issues/show_bug.cgi?id=4835

Bye,
bearophile

On Tuesday, 16 July 2013 at 10:37:59 UTC, eles wrote:

> Isn't the promotion to int so awful? Better ideas? (yes, I know
> about casting to long).

What do you mean, there is no promotion to int here.

On Tuesday, 16 July 2013 at 11:14:44 UTC, bearophile wrote:
> eles:
>
> Bye,
> bearophile

Walter: "Consider all the addressing modes used - they are all adds, with no overflow checks. Secondly, they all rely on wraparound (overflow) arithmetic, after all, that is how subtraction is done."

I think the way to go is to introduce "sanitized" integral types,
in conjunction with some compiler flag. If one day Walter agrees
with... This way, everybody is free to use whatever it likes.

On Tuesday, 16 July 2013 at 11:14:44 UTC, bearophile wrote:
> eles:
>
> Bye,
> bearophile

Don C.: "There's a root cause issue -- integer overflow is not an
error in general. The paper which bearophile keeps posting, which
he has apparently never read, shows quite convincingly that you
cannot make it an error in a C-family language. There are just
too many legitimate uses of integer wraparound.

eg. int.max + 200 - 300 should not be an error."

Frankly, I keep thinking if FreePascal didn't nail it the good
way: consider all integral values as belonging to the widest
integral type, perform calculation (as if) in that type, then
truncate (if needed) only the final result, on assignment.

eles:

> Don C.: "There's a root cause issue -- integer overflow is not an error in general. The paper which bearophile keeps posting, which he has apparently never read, shows quite convincingly
> that you cannot make it an error in a C-family language. There
> are just too many legitimate uses of integer wraparound.
>
> eg. int.max + 200 - 300 should not be an error."

See:
http://d.puremagic.com/issues/show_bug.cgi?id=9850

Bye,
bearophile

eles:

> Don C.: "There's a root cause issue -- integer overflow is not an error in general.

A good design for a modern language is to offer safe numbers on default, and overflowing/modular integral types for the uncommon cases where the programmer wants such behaviors.

Bye,
bearophile