Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56758
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4EDB6DB0.2050909@akbkhome.com>
References: <4EDA4989.2010702@akbkhome.com> <4EDB6DB0.2050909@akbkhome.com>
Date: Sun, 4 Dec 2011 11:44:03 -0200
Message-ID: <CA+5g0SLsBsb=71+FO3W+ta04g8TvQb+QZBp_1XOP_Gjqv-W89g@mail.gmail.com>
To: Alan Knowles <alan@akbkhome.com>
Cc: 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: felipensp@gmail.com (Felipe Pena)

Hi,

2011/12/4 Alan Knowles <alan@akbkhome.com>:
> This is ready for review now.
>
> https://bugs.php.net/patch-display.php?bug=3D60362&patch=3Dfix_disabling_=
bad_string_offsets&revision=3D1323002696
>
> This resolves the worst behavior changes introduced by the dereferencing =
of
> strings fix.
> https://bugs.php.net/bug.php?id=3D60362
>
> All tests (in Zend/tests) pass (after they have been modified to suit the
> change)
>
> Please review / comment...
>
> Regards
> Alan
>
>
>
> On Sunday, December 04, 2011 12:08 AM, Alan Knowles wrote:
>>
>> I've had a look at making string offsets of strings a bit saner.
>>
>> At present with the fix for array dereferencing : =C2=A0?search=3Dhello =
and a
>> test like isset($_GET['search']['name']) =C2=A0results in true, which is=
 has
>> potential security problems and is very confusing for any programmer fin=
ding
>> and working out why something like that may be failing.
>>
>> To solve this quite a few people agreed that not allowing non-numeric
>> string offsets on strings would be the smart way to go, the change is go=
ing
>> to break BC, so the idea is to at least not break it too badly...
>>
>> This patch is a start.
>>
>> https://bugs.php.net/patch-display.php?bug_id=3D60362&patch=3Dfirst_effo=
rt_to_fix_this&revision=3Dlatest
>>
>> It's been quite a while since I hacked on the engine, so the patch only
>> works reasonably well.. (see the FIXME on the tests at the bottom of the
>> patch.)
>>
>> The patch changes the following:
>> =C2=A0* $s =3D "string"; =C2=A0$s['offset'] -- produces a warning (and r=
eturns an
>> empty string)
>> =C2=A0* $s =3D "string"; =C2=A0$s['1'] -- works as before..
>> =C2=A0* $s =3D "string"; =C2=A0$s[true] $s[false] $s[0.1] -- give a noti=
ce (cast it to
>> an int if you want to get rid of the notice) - however work as before.
>> =C2=A0* changes the warning on invalid indexes to say "Uninitialized or
>> invalid" rather than just "Uninitialized"
>> =C2=A0* fixes most of the related tests
>>
>> I would appreciate if someone with better engine knowledge would have =
=C2=A0a
>> look and work out what the "BAD" usage should return.
>>
>> In theory.. the fetch_dim behavior should be return a empty string if an
>> invalid offset is used, or uninitialized zval if ISSET is calling it
>>
>> Regards
>> Alan
>>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Take a look at Zend/tests/offset_assign.phpt, there is a path hardcoded.

--=20
Regards,
Felipe Pena