Bug 13606 – erroneous overflow error in negative long literal

the following code fails to compile with message "Error: signed integer overflow", but -9223372036854775808L is correct negative value for long: long n = -9223372036854775808L; for those who are as lazy as me: -9223372036854775808L is -0x8000_0000_0000_0000L. this is valid negative value, albeit somewhat special, as it has no corresponding positive value. ;-)

p.s. i know about workaround with "-9223372036854775808uL", yet i'm sure that compiler should not reject this value with just "L".

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

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

(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; }

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

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

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.

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

Duplicate of #8929?

You're right, it's a duplicate. Thanks for the note! *** This issue has been marked as a duplicate of issue 8929 ***