Live data from Hacker News

PHP: md5('240610708') == md5('QNKCDZO')

3v4l.org

121–130 of 185 posts

Re: PHP: md5('240610708') == md5('QNKCDZO')

#121

I'm not exactly clear on how PHP == works, but you can see the MD5 for yourself: $ echo -n 240610708 | md5sum 0e462097431906509019562988736854 - $ echo -n QNKCDZO | md5sum 0e830400451993494058024219903391 - $ echo -n aabg7XSs | md5sum 0e087386482136013740957780965295 - All of them start with 0e, which makes me think that they're being parsed as floats and getting converted to 0.0. This is why "magic" operators like =…

So, you should use the old shell trick of adding an "X" to the front of the strings before comparing?

Or use === instead of ==.

The PHP developers have been pretty honest about the mistakes they made early on because they didn't know better. Unfortunately, many of those mistakes persist. The difference between == and === is one of the more well-known mistakes.

Re: PHP: md5('240610708') == md5('QNKCDZO')

#122

Earlier quoted context omitted.

> I used an MD5 hash as session id > Never used PHP for anything important since. The problem here isn't PHP, the problem here is you.

Nah, the problem is PHP. See: http://blog.codinghorror.com/falling-into-the-pit-of-success... > When you write code in [PHP], you're always circling the pit of despair, just one misstep away from plunging to your doom.

I'd be willing to say this is true for any language in varying ways.

Re: PHP: md5('240610708') == md5('QNKCDZO')

#123
post #116
post #96

Earlier quoted context omitted.

Ahh PHP, the language where true == false php > if ((true == "foo") && ("foo" == 0) && (0 == false)) echo "yay!"; yay!

This truly just bummed me out :(

Don't let it - he understands exactly how the types are being converted in order to make it appear that true == false.

This sort of thing happens in type conversion languages. You can either use === to stop conversion or you can understand how conversion works.

I'm not sure how the order of conversions is decided by PHP, but here's a brief explanation:

Compare "foo" to true. Convert the string "foo" to a boolean value. As it is desirable that a non-empty string evaluate to true, we will say they are "equal."

Compare "foo" to 0. Convert the string "foo" to a numeric value. As "foo" does not start with 0x it cannot be hex, and as it does not start with 0 it cannot be octal, so evaluate it as decimal - there are no numbers before the first letter so the string foo, when numerical, is 0.

Evaluate 0 to false. Well, that's just binary now isn't it? Of course false and 0 are equal!

The moral of the story, == is not "exactly equal" it is "relatively equal."

Re: PHP: md5('240610708') == md5('QNKCDZO')

#124
post #41

As a rough generalization, all PHP code that involves "==" and "!=" should be considered broken. PHP introduced "===" and "!==" a long time ago, and every programmer should know that they have to use that, without any excuses. Also, don't use "in_array($a, $b)", but use "in_array($a, $b, true)" instead.

So what you're basically saying is that the "standard" variations and APIs which people will find and use are broken, and the ones actually working are hidden somewhere in the documentation. And you're saying you think this is just fine? In that case, I have a hammer to sell you, and I think you know which one. http://blog.codinghorror.com/the-php-singularity/

> And you're saying you think this is just fine?

Not sure where you read this. I didn't provide any judgement of the situation.

Strawman arguments like this should have no place on HN.

Re: PHP: md5('240610708') == md5('QNKCDZO')

#125
I agree that all languages have it's warts and a good programmer should know about them.

I think what makes both PHP and Javascript not so great is the fact that it is so easy to overlook deadly mistakes like using "==" instead of "===" or forgetting to add a "var". And worst of all those errors can go unnoticed until something breaks and when it does it's pretty hard to find out the root of the problem.

Re: PHP: md5('240610708') == md5('QNKCDZO')

#126
post #84

Earlier quoted context omitted.

PHP's type coercion is nothing like I have every seen in any other language. Its horrendously messy, ugly and completely inexcusable. Is it objectively worse than type coercion in JavaScript?

Oh yes. In Javascript, the operands are only coerced if one of the operands is a number. So when comparing two strings (regardless of whether the strings can be interpreted as a number), you always get a regular string compare. "12" == "12.0" -> false, basic string compare Furthermore, if one operand happens to be a number, and the other operand has illegal characters to be interpreted as a number, the two operands a…

While it is obvious that PHP's == operator is horrible, JavaScript has its share of pretty bad issues, like "x" - 1 giving NaN.

What I don't understand is why some people agree that PHP is a horrible language, while at the same time praising JavaScript as messiah of scripting. These two languages don't just have problems, they have very similar problems. Moreover, they gained popularity for very similar reasons (lack of choice).

Seriously, if you posted something similar to OP about JavaScript the first thing people would tell you is "What, you're still not using ===?!"

Re: PHP: md5('240610708') == md5('QNKCDZO')

#127
post #41

As a rough generalization, all PHP code that involves "==" and "!=" should be considered broken. PHP introduced "===" and "!==" a long time ago, and every programmer should know that they have to use that, without any excuses. Also, don't use "in_array($a, $b)", but use "in_array($a, $b, true)" instead.

>without any excuses... Oh yea? How about this, http://www.reddit.com/r/PHP/comments/2zhg6z/how_true_is_this...

I don't see how "==" would help in that situation, other than "solving" this particular issue by opening another can of worms.

You simply can't use php arrays for user-generated keys in a safe manner. At least you have to add some prefix like '_stuff_' to all keys, to avoid accidental conversions. And yes, this "proper" solution (Can you ever can say "proper" in php? Anyway ...) doesn't have to involve "==", but works perfectly (and preferably) with "===".

Re: PHP: md5('240610708') == md5('QNKCDZO')

#128
post #16

Earlier quoted context omitted.

This, combined with the fact that you can increment strings gives some 'interesting' results: $a = "2d9"; $a++; echo $a . "\n"; $a++; echo $a . "\n"; Output 2e0 3

Who tries to increment strings anyway? What is your point here?

Given how happy PHP is about converting strings to integers on demand, it would be pretty easy to take string input intended to be a number, forget to actually convert it, and go around using it happily until one day you accidentally set off a bomb.

Re: PHP: md5('240610708') == md5('QNKCDZO')

#129
post #123
post #116

Earlier quoted context omitted.

This truly just bummed me out :(

Don't let it - he understands exactly how the types are being converted in order to make it appear that true == false. This sort of thing happens in type conversion languages. You can either use === to stop conversion or you can understand how conversion works. I'm not sure how the order of conversions is decided by PHP, but here's a brief explanation: Compare "foo" to true. Convert the string "foo" to a boolean valu…

The problem with designing a language that does these sorts of implicit type conversions is that the "equality" operator violates the fundamental properties of equality. Since grade school mathematics we are all taught that equality is symmetric and transitive, and PHP's == operator is neither.

Re: PHP: md5('240610708') == md5('QNKCDZO')

#130
post #98

Earlier quoted context omitted.

Once I wrote a little PHP application to manage a clan in a browser game. I used an MD5 hash as session id that I checked with if(session_id) When users started reporting that their logins would sometimes not work at the first time, I found out that strings that start with zero are coerced to 0 and then interpreted as false. Never used PHP for anything important since.

To be fair, this kind of thing (maybe not exactly this, but type-coercion bugs) can happen in JavaScript, which is all the rage now for "important" stuff.

Yeah but javascript has 'use strict' whereas PHP decided that the easter egg "looks like you're using the wrong language!" was more important than actually allowing a 'use strict' to force === instead of ==.
Post reply on HN