Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60504
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <op.wdxjzrzmidpuyk@slws007.slhq.int>
References: <CAPmfwEnMypV6DFRnRsnCvj+KQk1JG54TX3r1DNHQO3QQ0f+hjA@mail.gmail.com>
	<CAEZPtU4B0HpVrD4nzN6Cm+ogpza=qeyyfA1qSoRiyFF-dh6iFQ@mail.gmail.com>
	<CAORXhGLkKPY=GpfESDqiCVUhG4vZG7PmqK-v7780fGmvnQyeNw@mail.gmail.com>
	<4F847B8A.9010007@sugarcrm.com>
	<733bc8ea59cf6737563a62886e92fcb6.squirrel@www.l-i-e.com>
	<CAHMUw2Ft49f32di4nyOVWhzi-6Qn7u6yP4La2x_Wn2tZK-CHPA@mail.gmail.com>
	<CAL0xaBFKZySc4y72GS45t3En9g-6_RCzacvR3uf-N4fcaxymEA@mail.gmail.com>
	<CAKOpQSyrL_yVqEoxxpN+sWcQ9H6JjRQncpRnnG4BedjMRxrUqw@mail.gmail.com>
	<op.wdxjzrzmidpuyk@slws007.slhq.int>
Date: Mon, 7 May 2012 02:22:50 -0700
Message-ID: <CAKOpQSzn49CtV3tTX8=QaKV7ungLyXixxak2pesgWjpDeK6NCA@mail.gmail.com>
To: Gustavo Lopes <glopes@nebm.ist.utl.pt>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=f46d04428dca60138104bf6ed036
Subject: Re: [PHP-DEV] [off] PHP: a fractal of bad design
From: kris.craig@gmail.com (Kris Craig)

--f46d04428dca60138104bf6ed036
Content-Type: text/plain; charset=ISO-8859-1

On Mon, May 7, 2012 at 1:46 AM, Gustavo Lopes <glopes@nebm.ist.utl.pt>wrote:

> On Mon, 07 May 2012 10:31:00 +0200, Kris Craig <kris.craig@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

--f46d04428dca60138104bf6ed036--