Bug 4835 – DMD should warn about integer overflow in computed constant

I got bitten by this when I wanted to create a 6GB large file to test 64 bit support in std.stdio with dmd 2.048. The output of: import std.stdio; void main(string args[]) { long l_dangerous = 1024 * 1024 * 1024 * 6; writefln("l_dangerous = 0x%x", l_dangerous); writefln("l_dangerous = %s", l_dangerous); long l_ok = 1024 * 1024 * 1024 * 6L; writefln("l_ok = 0x%x", l_ok); writefln("l_ok = %s", l_ok); return; } is l_dangerous = 0xffffffff80000000 l_dangerous = -2147483648 l_ok = 0x180000000 l_ok = 6442450944 dmd 2.048 did not issue a warning about the integer overflow (neither with or without -w)

I'm asking for overflow detection for years (both at compile-time and run-time). Again here the C language is better than the D language: // C code #include "stdio.h" int main() { long long x = 1024 * 1024 * 1024 * 6; printf("%lld\n", x); return 0; } GCC 4.3.4 gives: prog.c: In function ‘main’: prog.c:3: warning: integer overflow in expression D compiler is not _practical_ enough yet.

Mass migration of bugs marked as x86-64 to just x86. The platform run on isn't what's relevant, it's if the app is a 32 or 64 bit app.

An example in Go language: package main func main() { var x uint32 = 1 << 40 var y = 1024 * 1024 * 1024 * 6 } The Go compiler gives the errors: test.go:3: constant 1099511627776 overflows uint32 test.go:4: constant 6442450944 overflows int

Another example in Go: package main func main() { var x uint64 = 1 << 90 } The Go compiler gives the error: test.go:3: constant 1237940039285380274899124224 overflows uint64

(In reply to comment #4) For completeness, it also does not have a problem (like in your example) where the initializer of the 64-bit variable is initialized with (what is not obvious) a folded and truncated 32-bit int: var x uint64 = 4 * 1024 * 1024 * 1024; // x is now 4294967296, not 0.

uint foo() { uint x = 1 << 40; return 1 << 90; } gives: foo2.d(3): Error: shift by 40 is outside the range 0..31 foo2.d(4): Error: shift by 90 is outside the range 0..31

(In reply to comment #6) > uint foo() { > uint x = 1 << 40; > return 1 << 90; > } > > gives: > > foo2.d(3): Error: shift by 40 is outside the range 0..31 > foo2.d(4): Error: shift by 90 is outside the range 0..31 I was aware of that. I have added the 1<<90 example to show the peculiar error message given by Go, that contains 1237940039285380274899124224, that is larger than a ulong.

(In reply to comment #8) > https://github.com/D-Programming-Language/dmd/pull/1803 An error, even :-) So the issue name should be updated. Thank you Walter. Let's see how this patch goes.

(In reply to comment #9) > (In reply to comment #8) > > https://github.com/D-Programming-Language/dmd/pull/1803 > > An error, even :-) So the issue name should be updated. > > Thank you Walter. Let's see how this patch goes. I hope the feedback I provided with being bitten by this corner case helped nudge this issue to the limelight, that way I can feel slightly important ;-). Thanks for addressing it so quickly Walter. (Also, isn't it strange that this was addressed quicker than in Java, which should have a larger support community, where the issue remains? Go D! (At least it remains with javac 1.6.0_43))

While I disagree with bearophile about doing such checks at runtime, due to the performance cost, doing them at compile time is a whole 'nother story.

(In reply to comment #11) > While I disagree with bearophile about doing such checks at runtime, due to the > performance cost, doing them at compile time is a whole 'nother story. Why don't you make the runtime over/underflow checks opt-in? (compiler option). There's a 0 performance cost that way, both for debug and release, by default, so no performance excuse. Then we can always discuss it later if it should be opt-out for the debug builds.

Because it'll screw things up right and left, for example, address calculations.

(In reply to comment #11) > While I disagree with bearophile about doing such checks at runtime, due to the > performance cost, A feature of LLVM 3.3, it seems those costs are not too much large for C language: http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation See: -fsanitize=signed-integer-overflow -fsanitize=integer More info: http://embed.cs.utah.edu/ioc/

(In reply to comment #13) > Because it'll screw things up right and left, for example, address > calculations. Walter, what do you mean, screw? Is that a limitation of the dmd backend, or are you arguing that it is problematic in general? LLVM implements it, as bearophile points out...

(In reply to comment #15) > Walter, what do you mean, screw? Is that a limitation of the dmd backend, or > are you arguing that it is problematic in general? LLVM implements it, as > bearophile points out... 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.

*** Issue 13785 has been marked as a duplicate of this issue. ***

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18298 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB