'9223372036854775807' == '9223372036854775808'

https://bugs.php.net/bug.php?id=54547

by moe • 14 years ago

129 135 14 years ago

bugs.php.net

DiabloD3• 14 years ago

The fact PHP fails at floating point math isn't news (and I swear I've seen this exact bug somewhere, same numbers and everything, somewhere else)...

Its the fact PHP refuses to fix it that is the news.

bonzoesc• 14 years ago

To anybody not familiar with PHP, it appears to fail at string comparison.

zdouglas• 14 years ago

Arguably, such an obtuse implicit cast is failure at string comparison.

ctdonath12• 14 years ago

Appears? It DOES fail at string comparison. They're strings. You can't make it any plainer that they're strings. Sometimes, like with barcode processing, strings contain only numeric characters - they're still strings regardless. If I can't ask if one string literal is equal to another string literal without it making a concerted effort to not just convert both strings to integers (which, BTW, would be fine so long as it preserved all digits) but to then convert it from a non-lossy to a lossy data type - that's TWO unwarranted type conversions - then the axioms of the language are untenable, rendering it useless in the real world and making it little more than a toy.

If you're going to run with PHP's axioms, then the specifications should (1) demand an unlimited-length integer type, and (2) NEVER convert a non-lossy to lossy data type without very good overt reason.

Fail.

kba• 14 years ago

http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de... was on Hacker News at few days ago with a link to http://phpsadness.com/sad/47.

gloob2• 14 years ago

This sort of thing is an intrinsic property of floating point math. It has limited precision. When the numbers get sufficiently large, that precision is insufficient to distinguish successive integers. That is to say, this is symptomatic of PHP implementing floating point stuff correctly.

This is what ghci (Haskell) says:

  Prelude> 9223372036844775807 == 9223372036844775808
  False
  Prelude> 9223372036844775807.0 == 9223372036844775808.0
  True

This is what Python says:

  >>> 9223372036844775807 == 9223372036844775808
  False
  >>> 9223372036844775807.0 == 9223372036844775808.0
  True

Here is what SBCL (Common Lisp) says:

  * (= 9223372036844775807 9223372036844775808)
  NIL
  * (= 9223372036844775807.0 9223372036844775808.0)
  T

Lua:

  > print(9223372036844775807 == 9223372036844775808)
  true (!!!!!)
  > print(9223372036844775807.0 == 9223372036844775808.0)
  true

Javascript:

  alert(9223372036844775807 == 9223372036844775808)
  true (!!!!!)
  alert(9223372036844775807.0 == 9223372036844775808.0)
  true

Other languages that will also do this[1]: Javascript, Lua. Languages that won't: anything with actual, honest-to-god integers, and not floats or doubles masquerading as them.[2] Languages that actually handle numbers sensibly: Lisp.[3] I'm not familiar with any others that actually treat rational numbers like rational numbers, but I expect there are some. (It's still, of course, impossible to treat real numbers like real numbers, meaning that this sort of thing will also happen there.)

[1] Well, not the string-to-number bit, but whatever.

[2] Except for the niggle that they'll still do this when you're using floating point numbers, because this is what floating point numbers do.

[3] https://en.wikipedia.org/wiki/Numerical_tower

eblume4• 14 years ago

I think you may be missing the point, or maybe it's I who am missing the point. Your three very thorough examples are a good way of showing how (most?) languages handle floating-point arithmetic vs. arbitrary arithmetic.

But it seems to me - and let me stress that I am not a PHP developer and won't be bothered to install PHP on my machine at this time - that PHP is failing to exhibit exactly the behavior your code examples are giving.

Put it another way - type coercion 'run amok' being another thing entirely, you are correct that this bug stems from the fact that PHP is converting these integers to floating-point, and the standard floating point implementations will all behave in this exact way (thus, not a PHP bug.)

However, the issue here is that (again, "most?") languages also provide an easy way to get to arbitrary-precision arithmetic - and indeed, in the three examples you posted, you simply encode in the most natural way (by simply writing them) the two integers and they automatically compare correctly.

My understanding is that this is not the case in PHP, and that is a shame.

tmcb• 14 years ago

Lua internally represents any kind of number as a floating-point one.

http://www.lua.org/pil/2.3.html

hiddenbayes• 14 years ago

This behavior is documented here: http://php.net/manual/en/language.operators.comparison.php

  If you compare a number with a string or the comparison
  involves numerical strings, then each string is converted
  to a number and the comparison performed numerically.

muyuu4• 14 years ago

IMO this conversion should fail if the number represented is not valid, or fall back to arbitrary precision math (GMP library for instance), instead of silently making such a questionable conversion.

I generally avoid exceptions/error_levels in all languages but this is probably a good cause for them, in order to keep the rest backwards compatible.

fffggg5• 14 years ago

How do you test that it isn't valid? I think you may be underestimating the difficulty in predicting whether a particular decimal number can be accurately represented as a floating point type. It may be non-obvious, but the representation of precise numbers changes depending on the number base. For example, in base 10, we can't precisely represent 1/3. In base 3, we can (0.1). In base 2, we can't precisely represent 0.1, or 1/10. A simple number such as 0.1 has no precise representation in base 2.

In this case in php, the truncation happens due to loss of precision in the mantissa of the double precision float. But there are so many other ways to lose precision, I don't think it's reasonable to ask a language to attempt to account for them.

This is why languages should have clear rules about when type conversion occurs, and allow the user to prevent it when it isn't desirable.

edit: in fact, amusingly, php seems to be doing some non-standard stuff with its floats. I was going to make a point about how you can't determine if a double is a "correct" representation of a string decimal, but in mocking an example I discovered something odd. Check this out:

This is what one should expect:

$ ruby -e'puts "%5.25f" % 0.1'

0.1000000000000000055511151

$ perl -wle'printf "%5.25f\n", 0.1'

0.1000000000000000055511151

But in php:

$ php -r'printf("%5.25f\n", 0.1);'

0.1000000000000000000000000

$ php -r'printf("%5.25f\n", "0.1");'

0.1000000000000000000000000

Is php changing the type conversion? Or not using double precision at all?

wladimir• 14 years ago

Who ever thought of this? I can understand "don't use == for strings", or implicit conversion when one of the arguments is a number, but this is extremely sneaky as it will only behave this way with two numerically-looking strings. Ouch. Why does it even do that check, wasting cycles beyond a normal string comparison? It looks like an elaborate and cruel trap for novice programmers.

Edit: I know == is not a string comparison. But you'd expect it to fail in a predictable way when passed strings that are not parseable as numbers, instead of trying to fall back on a string comparison so that people get the wrong idea.

dchest• 14 years ago

Not defending the bad design decision, but string comparison in PHP is strcmp, not ==.

pornel• 14 years ago

PHP gets input from various places, and one might want "1.00" from a form or URL to equal "1.0" read from a cookie or via database adapter that stringifies everything.

ctdonath12• 14 years ago

Ah, an obscure point of absurdity which utterly kills my pending interest in the language. If this sort of thing exists under the hood, revealed only by a detailed analysis of the specification, what other nonsense is there? Going so far as analyzing a string to determine whether it consists entirely of numbers for the non-sequitur process of then and only then converting it to what it isn't for logical evaluation is working pretty hard to do something counter-intuitive; might be tolerable if it actually preserved all digits, but not only does it work hard to convert a string to an integer, it then converts large integers in to floating-point values - not just one, but two layers of explicitly undesired and unnecessary and unreasonable typecasting.

I'm currently working with barcodes: numerical strings from 6 to 55 digits. In no way can I risk having one barcode be evaluated as equal to a literally different barcode just because the symbols in that string just happen to exhibit a passing resemblance to data of a different type.

Again, it's not just that it has loose typing. It's that it's taking what is OBVIOUSLY a string, converting it to an integer, THEN converting it to yet another data type which imposes data loss.

Intolerable for real-world use. A toy language. Alas, PHP, we hardly knew you...

ETA: Oh, I'd love to know the justification for the downvoting.

hackermom• 14 years ago

"Intolerable for real-world use. A toy language. Alas, PHP, we hardly knew you..."

Have you been out on the internet the past decade? Do you have a tendency to make extremities of things and trying to stand the needle on its tip?

whateverer7• 14 years ago

> Intolerable for real-world use. A toy language. Alas, PHP, we hardly knew you...

I'm sorry, I would like that to be true, but programmers rarely are half as smart as they think they are. We have many more years of PHP and its resulting insanity ahead of us.

kcbanner• 14 years ago

You could use strcmp like you're supposed to I suppose, or ===.

dunham• 14 years ago

Just do the /bin/sh thing and prepend "x" on the strings before comparing them. :)

jlarocco• 14 years ago

"Intolerable for real-world use. A toy language."

Seems like a silly thing to say. I wouldn't write avionics software with it, but there are a billion websites demonstrating that it's pretty decent for real-world use. At least as good as any other language, I'd guess.

tedunangst2• 14 years ago

Downvoting because you're railing against a language without understanding it. That, and your C++ comment above, make you sound like the programmer version of internet tough guy. Whatever your real life skills may be, it certainly sounds like a lot of posturing.

JadeNB• 14 years ago

> Going so far as analyzing a string to determine whether it consists entirely of numbers

I was about to give an outraged reply that, if PHP is like Perl, then it doesn't scan the string afresh, just keeps a flag indicating whether or not it thinks a string is numeric. However, it turns out that's not true at all. `Perl_looks_like_number`, defined in `sv.c`, calls `Perl_grok_number`, defined beginning on l. 577 (as of v5.14.2) in `numeric.c`, which (after some book-keeping) does this:

    if (s == send) {
      return 0;
    } else if (*s == '-') {
      s++;
      numtype = IS_NUMBER_NEG;
    }
    else if (*s == '+')
    s++;

    if (s == send)
      return 0;

    if (isDIGIT(*s)) {
      UV value = *s - '0';
      if (++s < send) {
        int digit = *s - '0';
        if (digit >= 0 && digit <= 9) {
          value = value * 10 + digit;
          if (++s < send) {
            digit = *s - '0';
            if (digit >= 0 && digit <= 9) {
              value = value * 10 + digit;
              if (++s < send) {
                digit = *s - '0';
                if (digit >= 0 && digit <= 9) {
                  value = value * 10 + digit;

and goes on and on and on and on in the same vein. Sheesh! (I didn't forget to close that last brace; the next line is de-dented, but that seems to be a mistake.)

danso• 14 years ago

What's the low-level cost to determine whether a given string is "numerical" or not? Also, would "001" be considered a numerical string?

This reminds me of Excel-like programs that by default, automatically detect (and convert) fields that appear to be dates/strings...often to catastrophic effect.

drunkpotato• 14 years ago

You just hit upon by far my least favorite bug in Excel. Any integers around I think 40000, which are quite easy to come upon in various datasets, are automatically "detected" as a date. It makes Excel very dangerous for reading CSV files.

extension2• 14 years ago

I can understand the rationale for coercing strings to numbers for an operation that is not valid on strings, but coercing strings to numbers just because it's possible is clearly a terrible idea. It's like they looked at JavaScript and decided that the == operator was just not hazardous enough.

nikic2• 14 years ago

Please have a look at the comments by "jabakobob at gmail dot com" and myself ("nikic@php.net"). They explain why such behavior is actually good, in most cases.

oconnore• 14 years ago

Well, "why such behaviour is good" is stretching it. Maybe just "why such behaviour is"?

ctdonath12• 14 years ago

Throwing away data without unavoidably good reason is BAD behavior. Period.

We've got gigabytes of RAM and terabytes of storage to work with; don't throw away characters in a string just because they don't fit in a compact data type used only because there is a passing resemblance of one to the other.

If I'm comparing two 53-digit barcodes, and they differ only by the last digit (checksum), then it's very important that comparing those two STRINGS comes up FALSE.

extension2• 14 years ago

If == is supposed to be a numeric comparison and you are supposed to use strcmp for strings then why does == (sometimes) work on strings? Make it always coerce to a number, or die trying. Overloading it as numeric or string compare depending on what the string looks like is ridiculous.

And BTW, things that work in most cases, but not all cases, are exactly where bugs come from.

mikeash8• 14 years ago

If it's mildly good in most cases as you claim, and catastrophically bad in certain cases as seems clear, then overall it's not a net gain.

This is what continually baffles me about PHP. There are plenty of bad languages out there, but PHP seems pretty much unique in having a community that actively resists any improvement and actively campaigns to keep the broken stuff around.

pestaa• 14 years ago

In this perspective, writing `strcmp` everywhere is not boilerplate, but a requirement.

(Such that

    strcmp('9223372036854775807', '9223372036854775808');

returns -1, meaning the strings are not equal.)

vladev• 14 years ago

No, you just need strict comparison (like you need it in JS and any other language with weak typing):

    php > var_dump('9223372036854775807' == '9223372036854775808');
    bool(true)
    php > var_dump('9223372036854775807' === '9223372036854775808');
    bool(false)

eblume4• 14 years ago

I beg your pardon, but you do not 'need it in JS', if 'it' is referring to using === instead of == to compare strings.

Here is what node.js says:

    > "9223372036854775807" == "9223372036854775808"
    false

caioariede• 14 years ago

You can do literal comparison using ===

But the problem in my perception is that it is very error-prone. A less error-prone solution would be only convert one string value to number when the another is really a number. For example:

'9223372036854775807' == 9223372036854775808

mistercow• 14 years ago

> A less error-prone solution would be only convert one string value to number when the another is really a number.

That is, in fact, exactly how JS handles it.

ndefinite3• 14 years ago

It's the same with JavaScript regardless of whether you use == or ===

9223372036854775807 == 9223372036854775808

true

9223372036854775807 === 9223372036854775808

true

tsuraan• 14 years ago

The difference being that the php code sample is trying to compare two strings.

eblume4• 14 years ago

Perhaps those two lines are the same in JS and PHP (I do not have PHP installed so I can't confirm, but I do have node installed):

    > 9223372036854775807 == 9223372036854775808
    true
    > 9223372036854775807 === 9223372036854775808
    true

However, that is not the two lines written about in this post. The following works as one would expect on JS, but (I assume, based on the report) not in PHP:

    > "9223372036854775807" == "9223372036854775808"
    false
    > "9223372036854775807" === "9223372036854775808"
    false

ndefinite3• 14 years ago

ah, I see. I missed that. I just checked in chrome's console and see false for both when they're strings.

debacle• 14 years ago

JavaScript doesn't have an fixed integer data type.

aGHz• 14 years ago

While this comment is beside the point, I'm still curious why this version works the way it does. I may be missing something obvious, but why does JS think those two integers are the same?

mkup2• 14 years ago

Probably due to implicit conversion to floating point format. After conversion, mantissa and exponent are the same, and least significant bits are truncated during conversion.

burgerbrain2• 14 years ago

Is "javascript does it too" supposed to be a defence?

ndefinite3• 14 years ago

More of an observation than anything else. I don't actually use PHP but find these recent PHP focused articles are helping me learn at thing or two about languages I do use.

fpp• 14 years ago

interesting when you see your comments on hacker news as submissions to hacker news a day later: ( http://news.ycombinator.com/item?id=3825132 )

"...My 5cents on that (recently published issues):

<? if ('9223372036854775807' == '9223372036854775808') { echo "I can not count!\n"; } ?> (see https://bugs.php.net/bug.php?id=54547)

built-in PHP web server dies with a large Content-Length header value: The value of the Content-Length header is passed directly to a pemalloc() call in sapi/cli/php_cli_server.c on line 1538. The inline function defined within Zend/zend_alloc.h for malloc() will fail, and will terminate the process with the error message "Out of memory". (see https://bugs.php.net/bug.php?id=61461) Luckily we are getting Javascript ready to replace all PHP on the server sooner or later ;-)..."

m_for_monkey• 14 years ago

You are bragging as if you invented that bug :)

Spoom• 14 years ago

Some of the comments on the bug report asking for the operation of == to change are misguided. Such a change would break many real-world applications. As I understand it, PHP is casting number-like strings to integers, and this fails because both numbers generated from the cast are above PHP_MAX_INT, so their values are undefined.

This is easily solved by using the type-checking === operator, which exists for that purpose.

I hesitate to say that this is a feature, not a bug, but it is clear that this is documented behavior.

jrockway4• 14 years ago

This is why I like programming languages with type systems and "numerical towers":

    Prelude> "9223372036854775807" == "9223372036854775808"
    False
    Prelude> "9223372036854775807" == 9223372036854775808

    <interactive>:1:25:
        No instance for (Num [Char])
          arising from the literal `9223372036854775808'
                   at <interactive>:1:25-43
        Possible fix: add an instance declaration for (Num [Char])
        In the second argument of `(==)', namely `9223372036854775808'
        In the expression: "9223372036854775807" == 9223372036854775808
        In the definition of `it':
        it = "9223372036854775807" == 9223372036854775808
    Prelude>

Yes. Strings are not numbers.

bromagosa• 14 years ago

You don't actually need type systems to test equality and identity the right way...

xyzzyz• 14 years ago

The point here is that these strings are neither equal nor identical.

postfuturist• 14 years ago

As a working programmer who has to use PHP, I just use === all the time and have long since moved on from even thinking about the insanity of PHP's == operator. Kinda like JavaScript programmers.

prodigal_erik• 14 years ago

This. PHP's "==" is yet another trap of incompetent language design and almost all code that ever used it does the wrong thing for some inputs. $x == $y && $y == $z doesn't even tell you that $x == $z, much less that $a[$x] == $a[$y].

ww5205• 14 years ago

A somewhat related story dealing with MaxInt in Javascript.

One of the worst bugs I've encountered years ago involved the conversion of Javascript int from string to number. Javascript's long integer has only 53 bits, while most other languages have 64-bit long int. When the backend language generated Javascript snippets (JSON) containing integers greater than 53 bits, the horror started at the frontend. Javascript happily truncated the int to 53 bits upon conversion from string to int. It was not a happy tale since those long integers were account numbers. The wrong accounts ended up getting updated, randomly at first appearance.

mikeash8• 14 years ago

I think the lesson there is that numeric types should only be used for things you actually want to do arithmetic with. An account ID that just happens to be all digits should still be stored and transmitted as a string.

ww5205• 14 years ago

The lesson I got was to be very careful about data type limitation when going across language boundary. The problem is not limited to numeric types. Different encoding and code page can screw up string values as well.

ars• 14 years ago

Judging by the huge number of stupid comments on that bug report this bug was posted on reddit.

If you don't actually use PHP (as most of the commenters seem not to) don't comment on the bug, it has nothing to do with you and you are just making noise.

fexl2• 14 years ago

This is how the strtol function in the standard C library works. Here's a test program:

    #include <stdio.h>
    #include <stdlib.h> /* strtol, strtod */

    /* Convert string to long and return true if successful. */
    int string_long(char *beg, long *num)
        {
        char *end;
        *num = strtol(beg, &end, 10);
        return *beg != '\0' && *end == '\0';
        }

    int main(void)
        {
        char *x_str = "9223372036854775807";
        char *y_str = "9223372036854775808";

        long x;
        long y;

        int x_ok = string_long(x_str, &x);
        int y_ok = string_long(y_str, &y);

        printf("x_str = %s\n", x_str);
        printf("y_str = %s\n", y_str);

        printf("x = %ld (ok=%d)\n", x, x_ok);
        printf("y = %ld (ok=%d)\n", y, y_ok);
        printf("x and y are %s\n", x == y ? "equal" : "not equal");

        return 0;
        }

And here's the output:

    x_str = 9223372036854775807
    y_str = 9223372036854775808
    x = 9223372036854775807 (ok=1)
    y = 9223372036854775807 (ok=1)
    x and y are equal

I compiled it like so:

    gcc -c -Wall -Werror -ansi -O3 -fPIC src/test_num.c -o obj/test_num.o

fexl2• 14 years ago

Incidentally if you try using those numeric constants directly in a C program, it fails to compile:

    #include <stdio.h>

    int main(void)
        {
        long x = 9223372036854775807;
        long y = 9223372036854775808;

        printf("x = %ld\n", x);
        printf("y = %ld\n", y);
        printf("x and y are %s\n", x == y ? "equal" : "not equal");

        return 0;
        }

The error message is:

    gcc -c -Wall -Werror -ansi -O3 -fPIC src/test_num2.c -o obj/test_num2.o
    src/test_num2.c: In function ‘main’:
    src/test_num2.c:6:11: error: integer constant is so large that it is unsigned [-Werror]
    src/test_num2.c:6:2: error: this decimal constant is unsigned only in ISO C90 [-Werror]
    cc1: all warnings being treated as errors

'9223372036854775807' == '9223372036854775808'

Related Stories