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
