Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56943
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.170 as permitted sender)
MIME-Version: 1.0
Sender: laruence@gmail.com
In-Reply-To: <4EED2BD0.7080903@sugarcrm.com>
References: <4EDA4989.2010702@akbkhome.com> <CAH-PCH76g4LwEwzaEvU3Hp7PeeyMUN4sc0uZExkedhHvYYnm9A@mail.gmail.com>
 <CABBJUpfNRaa580ZCtsYHCbDat1Sxbo7tNz2MiNQ68foPFTq61g@mail.gmail.com>
 <CABBJUpe2tWo68hpPrfovhDtFYVczU3-XhDD8ynh0i5E=vUnuFg@mail.gmail.com>
 <4EDC015C.3080701@akbkhome.com> <4EED2BD0.7080903@sugarcrm.com>
Date: Sun, 18 Dec 2011 11:31:59 +0800
Message-ID: <CABBJUpdze7mu_JdGGEZfMaw6092sTr4J4J2d7PvAmQZFtkqu5A@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Alan Knowles <alan@akbkhome.com>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Fixing string offsets of strings.
From: laruence@php.net (Laruence)

On Sun, Dec 18, 2011 at 7:54 AM, Stas Malyshev <smalyshev@sugarcrm.com> wro=
te:
> Hi!
>
> I think the idea behind this patch is good. I'll do final checks and appl=
y
> it tomorrow if no objections heard until then.
>
> Some notes:
>
>
>> $s =3D "string"; =C2=A0isset($s['offset']) returns false
>> This is pretty critical, as it's the only way to detect this situation,
>> and ensure that array tests do not return positive results for strings.
>> It also catches an obvious, but previously hidden and probably serious
>> bugs in the PHP code..
>
>
> This change concerns me a bit since it's a behavior change and provided t=
hat
> most of the people aren't actually aware that $s['offset'] means $s[0] it
> may lead to subtle code breakage. Then again, doing $s['offset'] leads to
> code breakage right now - I just encountered another bug caused by this i=
n
> production code mere days ago, code was checking that $s['offset'] is set
> without actually checking that $s is an array, and it happened to be not.=
..
>
>
>> $s =3D "string"; =C2=A0$s[' =C2=A02 =C2=A0']; and $s['2foo'] both emit e=
rrors, and return
>> false from isset() - the code pretty much uses is_numeric() internally.
>> - I'm pretty sure these would be un-intentional bugs, so behaving as
>> such seems consistent.
>
>
> Agreed, I think is_numeric is the right way.
>
>
>> I do not mind either way if $s['offset'] returns the first char or an
>> empty string, however it seemed a little inconstant to return false on
>
>
> Here I am conflicted. The right thing would be to return empty but it may
> cause some breakage. Then again, doing what we do now causes breakage rig=
ht
> now too (not new in 5.4, same breakage happening in 5.3 too) so I'm incli=
ned
> to go with false here unless somebody gives me a use case where it's usef=
ul
> for anything.
>
>
>> isset(), yet actually return a string. (although technically an empty
>> string does kind of indicate it is 'isset') - it at least leaves the
>> engine in a consistent state. Perhaps that change can wait's until 5.5..
>> thoughts...
>>
>> As for dropping the syntax for Strings eventually.. It would be nice,
>> but I'm not sure it is feasible anymore unfortunately.
>
>
> We tried to move to {} syntax but that didn't work, and probably isn't
> possible anymore without massive breakage.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
Hi:
    I think only trigger notice when a convertion of string to number
index  is a good way (trivial bc break).
    :)

thanks
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



--=20
Laruence =C2=A0Xinchen Hui
http://www.laruence.com/