Email or username:

Password:

Forgot your password?
Frost, Wolffucker 🐺:therian:'s posts Post Back to profile
Top-level
Paul Reinheimer

@woozle @Girgias @IceWolf @cptwtf @ramsey @Crell

My guess is that a lot of choices were made when ~everything came in as a string over GET or POST. PHP tried really hard to do what people probably wanted. Register Globals filled the world with strings!

18 January at 18:42 | Wall-to-wall | Open on phpc.social
4 comments
Woozle Hypertwin

@preinheimer @Girgias @IceWolf @cptwtf @ramsey @Crell

Well, PHP has remedied many other decisions that later turned out to be problematic -- I'd say this one is definitely ready to take its turn ^.^

18 January at 18:45 | Open on toot.cat
Larry Garfield

@woozle @preinheimer @Girgias @IceWolf @cptwtf @ramsey It's been a long effort to get this far. :-) And every change has someone whining that we've broken their app because it relies on silly implicit type conversions. Caution is needed as we go.

18 January at 19:07 | Open on phpc.social
Gina Peter Banyard

@preinheimer @woozle @IceWolf @cptwtf @ramsey @Crell yes, and frankly considering this premises comparing two strings as numerical makes _more_ sense than forcefully casting the string to an int, as it did prior to PHP 8.

But more importantly `==` Vs `===` is a nothing burger. The behaviour of `==` is important because this is the behaviour used with the ordering operators (e.g. `=<`).

And saying "eh just use `===`" kinda misses the point to why it is a problem.

19 January at 13:29 | Open on phpc.social
Woozle Hypertwin

@Girgias @preinheimer @IceWolf @cptwtf @ramsey @Crell

What doesn't make sense to me is that the operator would ever try to do type-conversion when it's comparing the same type on both sides, and where that type already has comparison rules (even for < and >).

Note that when the string-contents are not formatted as a number, all four operators just do what you'd expect (i.e. use string-comparison rules).

That means it must be first attempting to parse the string as a number, and only if that fails does it use string rules.

This seems wasteful of CPU, however trivially, in addition to the unexpected behavior.

...and given that this can cause false-positive matches specifically when looking at the output of a hash-function, I have to wonder if it doesn't also represent a security vulnerability.

Language opinions aside, the manual should at least clarify the point that all 4 operators will first try to compare two strings as numeric before falling back to what you'd expect -- and should probably note conditions under which two differing strings can be evaluated as equal (there are others, though probably more obvious/expected).

@Girgias @preinheimer @IceWolf @cptwtf @ramsey @Crell

What doesn't make sense to me is that the operator would ever try to do type-conversion when it's comparing the same type on both sides, and where that type already has comparison rules (even for < and >).

Note that when the string-contents are not formatted as a number, all four operators just do what you'd expect (i.e. use string-comparison rules).

19 January at 14:17 | Open on toot.cat
Go Up