Literal value of PHP_INT_MIN is converted to float

[ragol]

Description

The following code:

<?php

var_dump(-9223372036854775807);
var_dump(-9223372036854775808);
var_dump(PHP_INT_MIN);
var_dump(-9223372036854775807 - 1 === PHP_INT_MIN);
var_dump(-9223372036854775808 === PHP_INT_MIN);

Resulted in this output in PHP 8 (all versions):

int(-9223372036854775807)
float(-9.223372036854776E+18)
int(-9223372036854775808)
bool(true)
bool(false)

Resulted in this output in PHP 7 (all versions):

int(-9223372036854775807)
float(-9.2233720368548E+18)
int(-9223372036854775808)
bool(true)
bool(false)

But I expected this output instead:

int(-9223372036854775807)
int(-9223372036854775808)
int(-9223372036854775808)
bool(true)
bool(true)

PHP Version

all versions of PHP 7 and 8

Operating System

No response

[damianwadley]

Moved to doc-en.

This is because PHP does not parse -9223372036854775808 as a single negative number but instead first as the positive number 9223372036854775808 (then negated using the unary minus -) which is too large for an integer.

[ragol]

I would consider this to be a parser bug, not a documentation bug. Just because the parser does it this way does not mean that it is the correct way to do it.

[damianwadley]

It's also been that way for a very long time. Truth is there isn't a whole lot of need to try to coerce the parser to support negative literals just for this specific problem when you can solve this specific problem by writing PHP_INT_MIN instead.
See bug 53934 for more.

I'd compare to other languages but I can't think of any that handle integers the same way: Javascript doesn't distinguish between integers and floats strictly enough to be helpful here, Python and Ruby do arbitrary precision integers (more or less), and Perl switches between signed and unsigned integer storage.

[damianwadley]

And for the record: though this is mostly a duplicate of 53934, I think it would be nice to call out this issue in the integer documentation.
https://www.php.net/manual/en/language.types.integer.php

[ragol]

Compilers of other languages seem to be able to handle it. So I still consider it a bug in the parser. It is not super important since it is just this one edge case. As long as it is not fixed in the parser it should at least be clearly documented.

[ragol]

@damianwadley It seems really to be a duplicate of bug 53934. The second to last comment states that the the bug was fixed in documentation. That was in 2018. Unfortunately I cannot find it in the documentation.

[damianwadley]

The second to last comment states that the the bug was fixed in documentation. That was in 2018. Unfortunately I cannot find it in the documentation.

To track it down, note that the 2018 "automatic comment" deals with Subversion, while the one from 2020 comes with the Git commit ID b3e793a. The change adds the term "negation operator", suggesting that it is in fact an operation upon a number, but I think we can come up with something more explicitly stated than that.

[Girgias]

Duplicate of #2400