Thread overview
[Issue 13606] erroneous overflow error in negative long literal
Oct 12, 2014
Ketmar Dark
Oct 12, 2014
Ketmar Dark
Oct 12, 2014
Ketmar Dark
Nov 02, 2014
Kenji Hara
Nov 22, 2014
safety0ff.bugz
October 12, 2014
https://issues.dlang.org/show_bug.cgi?id=13606

Ketmar Dark <ketmar@ketmar.no-ip.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ketmar@ketmar.no-ip.org

--- Comment #1 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
p.s. i know about workaround with "-9223372036854775808uL", yet i'm sure that compiler should not reject this value with just "L".

--
October 12, 2014
https://issues.dlang.org/show_bug.cgi?id=13606

bearophile_hugs@eml.cc changed:

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

--- Comment #2 from bearophile_hugs@eml.cc ---
(In reply to Ketmar Dark from comment #1)
> p.s. i know about workaround with "-9223372036854775808uL", yet i'm sure that compiler should not reject this value with just "L".

-9223372036854775808L is a valid long value literal, so the compiler must accept it.

--
October 12, 2014
https://issues.dlang.org/show_bug.cgi?id=13606

--- Comment #3 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
(In reply to bearophile_hugs from comment #2)
> (In reply to Ketmar Dark from comment #1)
> > p.s. i know about workaround with "-9223372036854775808uL", yet i'm sure that compiler should not reject this value with just "L".
> 
> -9223372036854775808L is a valid long value literal, so the compiler must accept it.
by the way: it it correct to accept negative literals with "u" and "uL"? i'm thing that such literals should be rejected with "overflow" (or "underflow") error.

--
October 12, 2014
https://issues.dlang.org/show_bug.cgi?id=13606

--- Comment #4 from bearophile_hugs@eml.cc ---
(In reply to Ketmar Dark from comment #3)

> by the way: it it correct to accept negative literals with "u" and "uL"? i'm thing that such literals should be rejected with "overflow" (or "underflow") error.

I think they should be rejected by a modern and sanely designed language. Trying to convince Walter of this is hard.

Currently D accepts assignments from signed without errors or warnings, this is an example of "weak typing" in D:

void main() {
    ubyte x1;
    byte y1;
    x1 = y1;
    y1 = x1;
    ushort x2;
    short y2;
    x2 = y2;
    y2 = x2;
    uint x3;
    int y3;
    x3 = y3;
    y3 = x3;
    ulong x4;
    long y4;
    x4 = y4;
    y4 = x4;
}

--
October 12, 2014
https://issues.dlang.org/show_bug.cgi?id=13606

--- Comment #5 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
(In reply to bearophile_hugs from comment #4)
> Currently D accepts assignments from signed without errors or warnings, this is an example of "weak typing" in D:
yeah, it's bad. one can argue that we are not losing a bit of information here, but i think that this is wrong: we losing sign flag. so such assignment should be considered "unsafe".

with stressed safety it's strange that such assignments are allowed.

--
October 12, 2014
https://issues.dlang.org/show_bug.cgi?id=13606

--- Comment #6 from bearophile_hugs@eml.cc ---
(In reply to Ketmar Dark from comment #5)

> with stressed safety it's strange that such assignments are allowed.

Most persons have definition of "language safety" different from the D one. D is currently not very safe.

--
October 30, 2014
https://issues.dlang.org/show_bug.cgi?id=13606

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh@quickfur.ath.cx

--- Comment #7 from hsteoh@quickfur.ath.cx ---
This looks like two bugs in one... the first appears to be caused by parsing negative literals as the negation of the corresponding positive literal, and the second is the implicit cast from unsigned to signed, which has been a source of subtle bugs in D.

--
November 02, 2014
https://issues.dlang.org/show_bug.cgi?id=13606

Kenji Hara <k.hara.pg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|minor                       |enhancement

--- Comment #8 from Kenji Hara <k.hara.pg@gmail.com> ---
(In reply to hsteoh from comment #7)
> This looks like two bugs in one... the first appears to be caused by parsing negative literals as the negation of the corresponding positive literal, and the second is the implicit cast from unsigned to signed, which has been a source of subtle bugs in D.

Currently this is not a bug and the overflow error is expected behavior.

As hsteoh said, the negative unary operator '-' is not a part of integer literal.

-9223372036854775808L is parsed as a unary expression of negative operator '-' on the long literal 9223372036854775808L, and the overflowed signed literal which is typed as long by the suffix 'L' is rejected in lexer level.

http://dlang.org/lex#integerliteral

> 0L .. 9_223_372_036_854_775_807L	long

Long integer literal is limited up to 9_223_372_036_854_775_807.

To allow the code, we need to update spec to support "negative integer literal".

Change the importance to enhancement.

--
November 22, 2014
https://issues.dlang.org/show_bug.cgi?id=13606

safety0ff.bugz <safety0ff.bugz@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |safety0ff.bugz@gmail.com

--- Comment #9 from safety0ff.bugz <safety0ff.bugz@gmail.com> ---
Duplicate of #8929?

--
November 22, 2014
https://issues.dlang.org/show_bug.cgi?id=13606

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #10 from hsteoh@quickfur.ath.cx ---
You're right, it's a duplicate. Thanks for the note!

*** This issue has been marked as a duplicate of issue 8929 ***

--