Re: Fixing string offsets of strings.

From: Date: Sun, 04 Dec 2011 13:44:03 +0000
Subject: Re: Fixing string offsets of strings.
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-56758@lists.php.net to get a copy of this message
Hi, 2011/12/4 Alan Knowles <alan@akbkhome.com>: > This is ready for review now. > > > https://bugs.php.net/patch-display.php?bug=60362&patch=fix_disabling_bad_string_offsets&revision=1323002696 > > This resolves the worst behavior changes introduced by the dereferencing of > strings fix. > https://bugs.php.net/bug.php?id=60362 > > 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 :  ?search=hello and a >> test like isset($_GET['search']['name'])  results in true, which is >> has >> potential security problems and is very confusing for any programmer finding >> 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 going >> 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=60362&patch=first_effort_to_fix_this&revision=latest >> >> 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: >>  * $s = "string";  $s['offset'] -- produces a warning (and returns an >> empty string) >>  * $s = "string";  $s['1'] -- works as before.. >>  * $s = "string";  $s[true] $s[false] $s[0.1] -- give a notice (cast it to >> an int if you want to get rid of the notice) - however work as before. >>  * changes the warning on invalid indexes to say "Uninitialized or >> invalid" rather than just "Uninitialized" >>  * fixes most of the related tests >> >> I would appreciate if someone with better engine knowledge would have  a >> 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. -- Regards, Felipe Pena

« previous php.internals (#56758) next »