www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 4835] New: DMD should warn about integer overflow in computed constant

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4835

           Summary: DMD should warn about integer overflow in computed
                    constant
           Product: D
           Version: D2
          Platform: x86_64
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: lars.holowko gmail.com



PDT ---
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)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 07 2010
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4835


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs eml.cc



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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 07 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4835


Brad Roberts <braddr puremagic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Platform|x86_64                      |x86



---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4835




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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 26 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4835




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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 26 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4835


Luís Marques <luismarques gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |luismarques gmail.com



PDT ---


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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 26 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4835


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla digitalmars.com



13:14:08 PDT ---
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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 26 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4835






 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 26 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4835




19:06:55 PDT ---
https://github.com/D-Programming-Language/dmd/pull/1803

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 26 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4835






 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 26 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4835




PDT ---




 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))

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 26 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4835




22:36:40 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 26 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4835




PDT ---


 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 26 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4835




02:38:18 PDT ---
Because it'll screw things up right and left, for example, address
calculations.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 27 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4835






 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/

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 27 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4835




PDT ---


 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...

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 27 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4835




00:39:03 PDT ---


 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 28 2013