On Mon, May 7, 2012 at 11:22 AM, Kris Craig <kris.cr...@gmail.com> wrote:
> On Mon, May 7, 2012 at 1:46 AM, Gustavo Lopes <glo...@nebm.ist.utl.pt > >wrote: > > > On Mon, 07 May 2012 10:31:00 +0200, Kris Craig <kris.cr...@gmail.com> > > wrote: > > > > That being said, I agree that this *definitely* should be fixed if the > >> > >> examples cited are indeed accurate (I've been working with PHP for over > >> 10 years and I was never aware of this bizarre behavior, either). I > don't > >> know the history of this, but I at least would consider it to be a bug. > >> A rather large one, in fact; though I think some of the fears expressed > >> are a bit hyperbolic. And if you're fixing a serious bug or security > >> vulnerability, as a general rule of thumb, this automatically supercedes > >> any concerns regarding BC breakage IMHO. > >> > > > > This has already been discussed in its own thread, see > > http://comments.gmane.org/**gmane.comp.php.devel/72790< > http://comments.gmane.org/gmane.comp.php.devel/72790>; see also > > https://bugs.php.net/bug.php?**id=54547< > https://bugs.php.net/bug.php?id=54547> > > > > Doing away entirely with this behavior (e.g. making " 2" == "2" compare > > false) would be a rather large BC break, that discussion is restricted to > > whether integers in strings should be treated differently from integer > > literals for comparison purposes when their range is exceeded. I wrote a > > patch for that, and, while not really caring one way or the other, I'm > not > > convinced it's necessary and I some have consistency concerns (though > float > > overflows already get a similar treatment). > > > > -- > > Gustavo Lopes > > > > Agreed. While it's no secret that I believe optional strong typing would > be helpful in this context, setting that aside I would definitely not want > to see implicit conversions like "2" == 2 or even " 2" == 2 go away (though > I do wish more PHP devs were familiar with the various trim() functions > lol). > > That being said, this is what had me scratching my head from a previous > message in this thread: > > >$a = "123ABF453..."; //a password > >$b = "123DFEABC..."; //another one > >if ($a == $b){ > > //you're in. > >} > > > The thought that $a == $b would actually evaluate to TRUE is utterly > absurd.... Only catch is, it doesn't. As I was sharpening my pitchfork > getting ready to argue why this should be considered a bug and not > conflated with implicit conversions like " 2" == 2, I decided to do a > little test script against 5.3.11. I was unable to reproduce the behavior > being reported in the above example. In my tests, $a == $b returned FALSE. > As it should. > > juggling won't happen here, because both sides are strings, and they aren't numerical strings, so that example was bogus indeed. the discussion here is about whether it is not expected that the numerical strings will compared as numbers even in they can only represented as number if some kind of precision loss occurs. about numerical strings: 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<http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion> and the comparison performed numerically. These rules also apply to the switch<http://www.php.net/manual/en/control-structures.switch.php> statement. The type conversion does not take place when the comparison is === or !== as this involves comparing the type as well as the value." -- Ferenc Kovács @Tyr43l - http://tyrael.hu
