Live data from Hacker News

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

3v4l.org

141–150 of 185 posts

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

#141

Earlier quoted context omitted.

And in C we can do this to get TRUE: return (33 == '3'); :P

Incorrect. However, (0x33 == '3') will return true, as will (51 == '3'). Your point is valid, even if your code is wrong. Automatic type coercion can produce unexpected results in any language. PHP's automatic type coercion rules are designed to help newbies at the expense of experienced developers. C's automatic type coercion rules are, largely, designed to expose the underlying memory layout to developers who know…

Okay, I stand completely corrected.

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

#142
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

This is wonderful, I love it! Interestingly [1], this echoes "2e0" followed by "3" in hhvm-3.7.0, but "3" followed by "4" in hhvm-3.6.0. [1] http://3v4l.org/sJhP8

That means that someone was using this "feature" in a relatively core piece of code from the PHP ecosystem. Enough that hhvm felt they needed to support it.

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

#143
post #136
post #123

Earlier quoted context omitted.

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…

"This sort of thing happens in type conversion languages. You can either use === to stop conversion or you can understand how conversion works." Even JavaScript isn't insane enough to somehow coerce a string to 0.

Yes, JavaScript will convert strings into numbers

    console.log(5*"12");
    60
    console.log(5*"0x0C");
    60

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

#144

Earlier quoted context omitted.

And in C we can do this to get TRUE: return (33 == '3'); :P

Incorrect. However, (0x33 == '3') will return true, as will (51 == '3'). Your point is valid, even if your code is wrong. Automatic type coercion can produce unexpected results in any language. PHP's automatic type coercion rules are designed to help newbies at the expense of experienced developers. C's automatic type coercion rules are, largely, designed to expose the underlying memory layout to developers who know…

And there are no type-coercion rules at play in case of 51 == '3', because type of '3' is int (as per ISO 9899 p. 6.4.4.3.2).

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

#145

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 =…

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.

This does not appear to the case in PHP 5.6, even for most strings with '==' gotchas:

  
As far as I know the only strings that fail an if check are "" and "0". (Which is still a pitfall, but not one you'd hit with an MD5 hash)

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

#146
post #97

usual story == is not the same as ===

not the usual story , == should be deprecated and a warning should be displayed. PHP has explicit coercion features, devs should use them alongside with === .

I mean its the usual story when people post stuff about PHP comparisons.

http://php.net/md5

the example itself uses === although no advice why is given

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

#147

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.

You bought a new car. You took it out for a ride. a tree falls before you. You brake, but the car proceeded to hit the tree anyway. You call the car company and talk to their engineers. One of them ask. 'Did this happen on a Friday evening, when it was raining?' You say 'Yes, how do you know?' The engineer replies. "Our brakes does not work on rainy Friday evenings. If you REALLY want to brake on a rainy Friday eveni…

> You bought a new car.

There's your problem, wasting money on something that only depreciates in value. Tsk tsk.

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

#149
post #87
post #77

Earlier quoted context omitted.

> This is well-known PHP-trick. Use === to right result. Everybody knows PHP is a trickly-typed language. Read the docs people or PHP will take advantage of your gullible ass.

perhaps ==== operator must reserved

Absolutely! However, we must be careful not to define it in a too predictable way lest we violate the Principle of Most Surprise.

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

#150
post #144

Earlier quoted context omitted.

Incorrect. However, (0x33 == '3') will return true, as will (51 == '3'). Your point is valid, even if your code is wrong. Automatic type coercion can produce unexpected results in any language. PHP's automatic type coercion rules are designed to help newbies at the expense of experienced developers. C's automatic type coercion rules are, largely, designed to expose the underlying memory layout to developers who know…

And there are no type-coercion rules at play in case of 51 == '3', because type of '3' is int (as per ISO 9899 p. 6.4.4.3.2).

Excellent point. Thank you for the clarification. This is true in c99 as well.
Post reply on HN