Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:10732
Return-Path: <pollita@php.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 77875 invoked by uid 1010); 23 Jun 2004 16:34:15 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 77840 invoked by uid 1007); 23 Jun 2004 16:34:15 -0000
Message-ID: <20040623163415.77838.qmail@pb1.pair.com>
To: internals@lists.php.net
References: <20040622164209.23239.qmail@pb1.pair.com> <5.1.0.14.2.20040622180046.02e53768@127.0.0.1> <5.1.0.14.2.20040623000103.02f351b8@127.0.0.1>
Date: Wed, 23 Jun 2004 09:34:14 -0700
Lines: 63
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Posted-By: 169.229.135.175
Subject: Re: [PHP-DEV] Bug 28879: Populating arrays with resources and   objects as offsets
From: pollita@php.net ("Sara Golemon")

> >For myself, I agree with you.  Using resources as array offsets just
feels
> >wrong, and I'm more than happy to leave that be.  My only concern there
was
> >consistency with $arr[$res] = $val; behavior which *does* pickup the lval
> >and has since ages long past.
> >
> >But since there's no BC need to allow resources in array initialization,
> >then sure, leave it to the scripter to cast it to an int if that's REALLY
> >what they want. (Again "why?" comes to mind).
>
> You are right, which is a sucky inconsistency. Instead of "fixing" array
> initialization, maybe the right thing to do, is to add an E_WARNING to
> $arr[$res] instead? Or at least an E_STRICT.
>
I can get behind that approach.  That only leaves the severity level and
error text to be decided.  Given the behavior gap between these two, I vote
for E_WARNING.  How does this sound:

Index: Zend/zend_execute.c
===================================================================
RCS file: /repository/ZendEngine2/zend_execute.c,v
retrieving revision 1.649
diff -u -r1.649 zend_execute.c
--- Zend/zend_execute.c 18 Jun 2004 18:33:46 -0000 1.649
+++ Zend/zend_execute.c 23 Jun 2004 16:30:51 -0000
@@ -839,8 +839,10 @@
     }
    }
    break;
-  case IS_DOUBLE:
   case IS_RESOURCE:
+   zend_error(E_WARNING, "Resource ID#%d used as offset, casting to integer
(%d)", dim->value.lval, dim->value.lval);
+   /* Fall Through */
+  case IS_DOUBLE:
   case IS_BOOL:
   case IS_LONG: {
     long index;
@@ -3402,6 +3404,7 @@
     zend_hash_update(array_ptr->value.ht, "", sizeof(""), &expr_ptr,
sizeof(zval *), NULL);
     break;
    default:
+    zend_error(E_WARNING, "Illegal offset type");
     zval_ptr_dtor(&expr_ptr);
     /* do nothing */
     break;



> >The $arr[$obj] = $val; style raises E_WARNING, so it makes sense (to me)
to
> >do the same with the $arr = array($obj => $val); syntax.
>
> Yep, I agree. We should issue an E_WARNING in this case similar to
> $arr[$obj]. We should need to copy the illegal offset error msg.
>
See second block of above diff...

-Sara