On Thu, Nov 24, 2011 at 9:12 PM, Larry Garfield <la...@garfieldtech.com>wrote:
> On 11/23/2011 12:13 PM, Lester Caine wrote:
>
>> Richard Quadling wrote:
>>
>>> I agree with Daniel on this.
>>>
>>> Just looking for any test relating to isset() to see what tests will
>>> now fail.
>>>
>>
>> So it's not just me :)
>> I am seeing this break real world projects and can't see a easy way to
>> fix the break. There is nothing really wrong with the current code
>> except that the sub keys have yet to be populated.
>>
>
> This is going to be a huge problem for Drupal. Drupal uses deep
> associative array structures a lot, by design. That means we isset() or
> empty() on arrays a lot. I haven't had a chance to test it yet, but I see
> this change breaking, um, A LOT. And as Daniel noted, the fix is to turn
> one line of very readable code into 8 lines of hard to read code.
>
Did you managed to read the whole thread?
I'm asking because there were lot of confusion about the actual impact of
this problem, and Lester particularly seemed confused.
"There is nothing really wrong with the current code except that the sub
keys have yet to be populated."
that isn't true, if the array or some sub elements are empty("yet to be
populated"), you won't bump into this change. See my previous mail for the
exact details.
so the above mentioned one liner:
"if (isset($arr['package']['attribs']['version'])) {"
what could go wrong:
$arr is not an array, but a string -> it would fatal on 5.3(Fatal: cannot
use string offset as an array), but it would work with 5.4
$arr['package'] is not an array but a string -> false on 5.3, true on 5.4
(this is the worst case)
$arr['package']['attribs'] is not an array but a string -> true on both 5.3
and 5.4 (so you are already screwed)
the least amount of change to fix that isset would be:
isset($arr["package"]["attribs"]) && is_array($arr["package"]["attribs"])
&& isset($arr["package"]["attribs"]["version"]);
a little bit bit longer, right.
I think that if you can't guarantee your data, then you have to
check/sanitize it.
isset($array['foo']['bar']['baz']) could seem as a good idea, but don't
forget that if $array or one of it's element will be, for example an
object(not implementing ArrayAccess) then your isset will still fail with a
fatal error:
$arr = new StdClass;
isset($arr["package"]["attribs"]["version"]);
PHP Fatal error: Cannot use object of type stdClass as array
> This is not a step forward by any metric I can imagine. It's changing
> long-standing behavior for no real benefit I can see except perhaps strict
> adherence to a doc page. However, PHP has always been an "implementation
> is the standard" language, which means this is a language API change.
>
Stas and Etienne explained in this thread what was the reason introducing
this change(removing the string offset pseudo-type).
>
> Please roll it back to avoid breaking a crapton of existing, legitimate,
> non-buggy code.
This change would only break buggy code, where a string is checked as it
would be an array, and I would also argue about the crapton part.
As I mentioned before, if your input validation is so fragile, that you can
be bitten by this bug, then most probably you can also be bitten by the
same problem which exists in 5.3( see "$arr['package']['attribs'] is not an
array but a string").
The only real-world example where this breaks something was a test in the
PEAR codebase, albeit Daniel didn't mentioned the test, I have a feeling
that if we check it, we will see that the test itself is buggy (else it
couldn't have triggered this thread).
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
