invalid array key/index not generating notices

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