Andi Gutmans wrote:

At 03:49 AM 4/27/2004 +0000, Curt Zirzow wrote:

$a = 'a string';
/* E_ERROR Cannot use string offset as an array */
echo is_array($a['bar']['baz']);

I made this change back in December.
I guess I could revert back but I think it makes sense to be strict here.
What does the rest think?

My feeling is that the is_-functions should be forgiving as people
are doing checks to ensure proper input values. To force a combination
or isset and is_ seems to be the wrong thing to me. But I realize that
the issue here happens because is_* are normal functions and the check
is done beforehand. Nevertheless I'd prefer not to have to guard is_*
with isset in my ideal PHP world :-)

On one hand it's not that important to me though as it only happens
under rare circumstances. On the other hand it leads to very subtle BC
problems as you can hit it depending on user input in a form if you use
nested arrays there. So I'm 50:50 on reverting.

• Chris

Hello Andi,

be strict

marcus

Tuesday, April 27, 2004, 9:51:35 AM, you wrote:

I made this change back in December.
I guess I could revert back but I think it makes sense to be strict here.
What does the rest think?

Andi

At 03:49 AM 4/27/2004 +0000, Curt Zirzow wrote:

I can't seem to find any discussion on this BC issue, so forgive me if
this has already been discussed.

Given the following;

$a = 'a string';

/* E_ERROR Cannot use string offset as an array */
echo is_array($a['bar']['baz']);

/* non error resolution */
echo isset($a['bar']['baz']) && is_array($a['bar']['baz']);

I'm not sure, but the patch below does seem to make the E_ERROR
get demoted to a E_WARNING, thus fixing it so execution simply doesn't
stop when a string is referenced improperly. Or is it a must that php
needs to stop in this case?

Index: zend_execute.c

RCS file: /repository/ZendEngine2/zend_execute.c,v
retrieving revision 1.643
diff -u -r1.643 zend_execute.c
--- zend_execute.c 15 Apr 2004 21:32:34 -0000 1.643
+++ zend_execute.c 27 Apr 2004 02:39:52 -0000
@@ -898,7 +898,9 @@
zval ***retval = &T(result->u.var).var.ptr_ptr;

    if (!container_ptr) {

•           zend_error(E_ERROR, "Cannot use string offset as an array");
  

•           *retval = &EG(uninitialized_zval_ptr);
  

•           zend_error(E_WARNING, "Cannot use string offset as an array");
  

•           return;
    }
  
    container = *container_ptr;
  

Andi Gutmans wrote:

I made this change back in December.
I guess I could revert back but I think it makes sense to be strict here.

Reevaluating it I noted the following:
$a = 'foo'; $a['bar']['qux'] = 42; # error

$a = 42; $a['bar']['qux'] = 42; # warning
$a = true; $a['bar']['qux'] = 42; # warning

unset($a); $a['bar']['qux'] = 42; # works
$a = null; $a['bar']['qux'] = 42; # works
$a = false; $a['bar']['qux'] = 42; # works!

On the other hand
$a = 'foo'; $b = $a['bar']['qux']; # error

$a = 42; $b = $a['bar']['qux']; # works
$a = true; $b = $a['bar']['qux']; # works
unset($a); $b = $a['bar']['qux']; # works
$a = null; $b = $a['bar']['qux']; # works
$a = false; $b = $a['bar']['qux']; # works

Let me ask you one question: What it the real benefit of making it
fail? Isn't a notice or warning enough safety?

I think this should definitely be more orthogonal, i.e. work (with a
notice or warning) in all cases to avoid WTF.

[ $a = 'foo'; $a['bar'] = 42; has an even weirder behaviour: It results
in the string '4oo'... ]

• Chris