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. @Richard Could you clarify what you were trying to illustrate with that code? I wasn't able to find anything wrong with how PHP handled it. So either you were mistaken or I misunderstood your point (if the latter, please tell me how so I can try again to repro the problem you're raising concern about). So with that in mind, the point I raised in the second paragraph of my last email is moot because I was referring to behavior that doesn't actually exist (again, unless I was testing for the wrong thing somehow?). Implicit conversions like " 1" == 1.0 I fully support so long as they can both be converted to numbers without loss of precision. --Kris
