without getting involved with whether there is a bug here or not
(I neither have the karma or the insight to make that judgement),
I would like to offer the idea that an alternative coding style could
have averted the problem regardless of the lack of an E_NOTICE...
namely a more defensive coding style; some example code
to make this clear:
<?php
function some_func() { return; }
// D-FENS v1 (force the return value to be an array)
$a = (array) some_func();
if ($a["do_it"] == true) { // are you sure you dont want === ?
echo "just done it\n";
}
// D-FENS v2 (check the return value is an array)
$b = some_func();
if (is_array($b) && ($b["do_it"] == true)) {
echo "just done it\n";
}
// D-FENS v3
$c = some_func();
if (isset($c["do_it"]) && ($c["do_it"] == true)) {
echo "just done it\n";
}
// D-FENS v4 (for the truly paranoid :-)
$d = some_func();
if (is_array($d) && isset($d["do_it"]) && ($d["do_it"] == true)) {
echo "just done it\n";
}
?>
maybe this is food for thought for you/your team with regard
to defending against [such] mistakes - I know from experience that,
even though I am often the only developer on a project, it pays not to
make to many assumption about what should be returned from functions/methods.
Daniel Convissor wrote:
> Folks:
>
> I came across a subtle bug a developer introduced into our application.
> It took us a month to realize the bug was there because PHP didn't throw a
> notice. Here is a simplified version of what was happening.
>
> // function some_func() {}
> $a = some_func();
> if ($a['do_something'] == true) {
> // Do it.
> }
>
> some_func() was supposed to return an array. But it was returning void.
> So $a was NULL. Oops -- we all make mistakes. What's unfortunate is PHP
> didn't raise a "Notice: Undefined index: do_something" here. It would
> have saved us some headaches. I'm sure others have run into this as well.
>
> The following also doesn't produce a notice:
>
> $a = 12;
> echo $a['k']
>
> I looked through the bugs database and mailing list archive and came up
> with nothing on this particular issue. But bugs 29271, 30885 and 38165
> cover the situation where a key's string is auto-converted to 0:
>
> // While this is a behavior we all truly expect:
> $a = 'value';
> echo $a[0] . "\n"; // output: v
>
> // Another oddity, but people closing bugs say it's expected:
> $a = 'value';
> echo $a['k'] . "\n"; // output: v
>
> This last behavior is counter-intuitive, let alone un-documented.
it does become intuitive once you truly understand the way php autocasts
stuff - I'll happily admit it took a post from Rasmus (no less) on the
generals mailing list for me to start to really understand what goes on in
situations
such as these... I'll try to explain (and hope I don't do anyone an injustice):
1. $a is a string therefore only integers are allowed as 'keys' in the
'array notation' used for accessing offsets of the string directly
2. the 'key' is string and therefore converted a integer according to the
string-to-integer conversion rules... leading consecutive numeric characters
are taken to
be the integer and in cases where there is no leading numeric character the
string converts
to zero (not taking into account a leading sign character that might exist in
the
string e.g.
echo (int) "123string"; // 123
echo (int) "1string"; // 1
echo (int) "string"; // 0
>
> Wondering what the folks here think about this.
>
> Thanks,
>
> --Dan
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
