Comment #0 by david.eckardt — 2012-11-01T09:23:21Z
It cannot be named.
static assert (long.min == -9223372036854775807L);
// Error: static assert (-9223372036854775808L == -9223372036854775807L) is false
static assert (long.min == -9223372036854775808L);
// Error: signed integer overflow
Comment #1 by monarchdodra — 2012-11-01T14:27:09Z
(In reply to comment #0)
> It cannot be named.
>
> static assert (long.min == -9223372036854775807L);
> // Error: static assert (-9223372036854775808L == -9223372036854775807L) is
> false
>
> static assert (long.min == -9223372036854775808L);
> // Error: signed integer overflow
I don't think this has anything to do with voldermort, and this works just fine:
void main()
{
long a = -2L^^63;
assert(a == long.min);
long b = long.min;
assert(b == long.min);
}
It sounds more like an interpretation error, whereas *writing* "-9223372036854775808L;" causes an error.
My *guess* is interprets the decimal number into a long, and afterwards, the sign is applied. This chokes in this particular case, because the valid range for longs is [-2^^63, 2^^63-1], so the interpreted number overflows before the compiler has a chance to apply the sign:
long a = 9223372036854775808L; //WRONG
long b = -9223372036854775808L; //LEGAL
But that's just speculation on my part.
Comment #2 by clugdbug — 2012-11-02T03:17:37Z
(In reply to comment #1)
> (In reply to comment #0)
> > It cannot be named.
> My *guess* is interprets the decimal number into a long, and afterwards, the
> sign is applied. This chokes in this particular case, because the valid range
> for longs is [-2^^63, 2^^63-1], so the interpreted number overflows before the
> compiler has a chance to apply the sign:
Yes, of course that's what's happening. It is a number you cannot write as a literal, you can only use a euphemism like "long.min" or "-2L^^63".
Comment #3 by david.eckardt — 2012-11-02T05:16:23Z
Although no surprise, it might be worth noting that
mixin("static assert(long.min==" ~ long.min.stringof ~ ");");
causes the "signed integer overflow" error, too.
Comment #4 by yebblies — 2013-11-23T21:05:21Z
We could introduce arbitrary precision integer literals to fix this, but that's an enhancement. This works the same as it does in C.
Comment #5 by hsteoh — 2014-11-22T06:14:25Z
*** Issue 13606 has been marked as a duplicate of this issue. ***
Comment #6 by hsteoh — 2014-12-17T18:32:40Z
*** Issue 13842 has been marked as a duplicate of this issue. ***
Comment #7 by zaydek — 2017-05-30T18:05:10Z
I don't think this is a bug. I think it's operator precedence.
long(-9223372036854775808UL)
or
long l = -9223372036854775808UL
Just a little unintuitive is all.
Comment #8 by simen.kjaras — 2018-04-09T11:22:18Z
*** Issue 13762 has been marked as a duplicate of this issue. ***
Comment #9 by pro.mathias.lang — 2020-09-13T22:59:11Z
Nowadays, the `L` suffix is not required anymore, so the following compiles just fine:
```
static assert (long.min == -9223372036854775808);
```
I was about to say that we should fix this for C compatibility, but C has the same issue, as Daniel pointed out:
```
int main ()
{
long long a = -9223372036854775808LL;
return 0;
}
```
```
foo.c:3:20: warning: integer literal is too large to be represented in a signed integer type, interpreting as unsigned
[-Wimplicitly-unsigned-literal]
long long a = -9223372036854775808LL;
^
1 warning generated.
```
This sounds like a good entry for a FAQ. Closing as WONTFIX.