[RFC][VOTE] E_WARNING on invalid container read-adccess

Dan Ackroyd

10 years ago

> On 16 Aug 2016, at 16:55, David Walker <dave@mudsite.com> wrote:
>
> I'd like to go ahead and open up the RFC to voting to the scope
> that it is written.

Hi David,

Although I will almost certainly be voting yes, the vote does need 2/3's to pass.

All language changes require that, even if no syntax is changed.

cheers
Dan
Ack

Levi Morrison

10 years ago

On Tue, Aug 16, 2016 at 11:09 AM, Dan Ackroyd <danack@basereality.com>
wrote:

>
> > On 16 Aug 2016, at 16:55, David Walker <dave@mudsite.com> wrote:
> >
> > I'd like to go ahead and open up the RFC to voting to the scope
> > that it is written.
>
> Hi David,
>
> Although I will almost certainly be voting yes, the vote does need 2/3's
> to pass.
>
> All language changes require that, even if no syntax is changed.
>
> cheers
> Dan
> Ack
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

While "language change" is not well-defined I agree that the vote needs to
be 2/3 here.

David Walker

10 years ago

Will up the ante: I wasn't sure the RFC page on voting didn't really define
this, I have no probs with 2/3.

On Tue, Aug 16, 2016 at 11:13 AM Levi Morrison <levim@php.net> wrote:

Yasuo Ohgaki

10 years ago

Hi David,

On Wed, Aug 17, 2016 at 12:55 AM, David Walker <dave@mudsite.com> wrote:

> I raised this concept a couple weeks ago to a couple +1's.  Discussion was
> held mostly upon the PR [1], and I went through and documented within the
> RFC [2].  I'd like to go ahead and open up the RFC to voting to the scope
> that it is written.
>
> --
> Dave
>
> [1] https://github.com/php/php-src/pull/2031
> [2] https://wiki.php.net/rfc/notice-for-non-valid-array-container

Could you add performance analysis section?

Thank you.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Pascal MARTIN

10 years ago

Le 16/08/2016 à 17:55, David Walker a écrit :

> I'd like to go ahead and open up the RFC to voting to the scope
> that it is written.

Hi,

At AFUP, we would be +1 on this RFC.

Basically: it could/will help detect problems, and the behavior change
should not cause too many bc-breaks (actually, when it does cause some,
it'll - probably - mostly be by detecting problems/bugs).

Thanks for your work on this!

--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/

David Walker

10 years ago

Hi Internals,

My original time for vote ending was yesterday, however Yasuo requested I
provide some benchmarking stats to see performance impact.  I apologize I
wasn't able to provide the information sooner, I was off getting married.
I'd like to extend the vote through Sunday evening in the event anyone had
reservations based on potential performance impact.  The RFC is currently
sitting 15-0 in favor.

(added to RFC)
Execution Time (DualCore 3ghz; 2g ram)
* Current Master : ~0.09s (~489k operations)
* Current Master w/RFC Displaying Warnings: ~33.25s
* Current Master w/RFC Hiding Warnings: ~0.82s (~4.091m operations)

We can see there is a significant increase in operations on huge loads.
However, I wouldn't suspect 1m of these errors per request almost ever.
So, yes there is; but I'd call it useful information overhead.

--
Dave

On Tue, Aug 23, 2016 at 12:50 PM Pascal MARTIN, AFUP <
mailing@pascal-martin.fr> wrote:

Bishop Bettini

10 years ago

On Wed, Aug 24, 2016 at 10:58 AM, David Walker <dave+php@mudsite.com> wrote:

> I'd like to extend the vote through Sunday evening in the event anyone had
> reservations based on potential performance impact.  The RFC is currently
> sitting 15-0 in favor.
>

I'd recommend extending the original end date by a week, since internals
tends to vote in weekly intervals (an informal minimal reasonable response
time, I suppose).

> (added to RFC)
> Execution Time (DualCore 3ghz; 2g ram)
>   * Current Master : ~0.09s (~489k operations)
>   * Current Master w/RFC Displaying Warnings: ~33.25s
>   * Current Master w/RFC Hiding Warnings: ~0.82s (~4.091m operations)
>
> We can see there is a significant increase in operations on huge loads.
> However, I wouldn't suspect 1m of these errors per request almost ever.
> So, yes there is; but I'd call it useful information overhead.
>

I've not looked at the code. How much, if at all, does the RFC change the
happy path operation, on a test like this?

$a = [ 'foo' ];
for ($i = 0; $i < 1000000; $i++) { $a[0]; }

Notwithstanding, I feel the ops increase 10x is worth it: this is a subtle
code problem.

David Walker

10 years ago

On Wed, Aug 24, 2016 at 9:36 AM Bishop Bettini <bishop@php.net> wrote:

> On Wed, Aug 24, 2016 at 10:58 AM, David Walker <dave+php@mudsite.com>
> wrote:
>
>> I'd like to extend the vote through Sunday evening in the event anyone had
>> reservations based on potential performance impact.  The RFC is currently
>> sitting 15-0 in favor.
>>
>
> I'd recommend extending the original end date by a week, since internals
> tends to vote in weekly intervals (an informal minimal reasonable response
> time, I suppose).
>

Good to know the general convention here.  I'll extend a week until
Wednesday the 31st.

>
>
>> (added to RFC)
>> Execution Time (DualCore 3ghz; 2g ram)
>>   * Current Master : ~0.09s (~489k operations)
>>   * Current Master w/RFC Displaying Warnings: ~33.25s
>>   * Current Master w/RFC Hiding Warnings: ~0.82s (~4.091m operations)
>>
>> We can see there is a significant increase in operations on huge loads.
>> However, I wouldn't suspect 1m of these errors per request almost ever.
>> So, yes there is; but I'd call it useful information overhead.
>>
>
> I've not looked at the code. How much, if at all, does the RFC change the
> happy path operation, on a test like this?
>
> $a = [ 'foo' ];
> for ($i = 0; $i < 1000000; $i++) { $a[0]; }
>
> Notwithstanding, I feel the ops increase 10x is worth it: this is a subtle
> code problem.
>

That is my thoughts too.  When testing this change against my product I
uncovered 10 cases of this warning being raised (which was actually
helpful), but only ever 2-3 per request.  So I'd imagine it's never going
to come to the 1m+ happenings per request ever.

And for your given test case, since $a[0] is defined (as 'foo') the change
in this RFC is not triggered, so there is no difference between any of the
testings.

--
Dave

Christoph Becker

10 years ago

On 16.08.2016 at 17:55, David Walker wrote:

> I raised this concept a couple weeks ago to a couple +1's.  Discussion was
> held mostly upon the PR [1], and I went through and documented within the
> RFC [2].  I'd like to go ahead and open up the RFC to voting to the scope
> that it is written.
>
> [1] https://github.com/php/php-src/pull/2031
> [2] https://wiki.php.net/rfc/notice-for-non-valid-array-container

For the record, the RFC rightly claims:

| The default behavior, of a silent NULL return, is not correctly
| defined in the Array Documentation however is noted in a comment

I have documented this behavior now[3], and removed the note, which was
not quite correct, because it claimed that TRUE would be returned when
array dereferencing NULL, bool or int.

[3] <http://svn.php.net/viewvc?view=revision&revision=339937>

--
Christoph M. Becker

Dmitry Stogov

10 years ago

I vote NO, because the implementation introduces more problems than intents to fix.

For example the following code starts to throw exception:

<?php $a = [null]; $c = null; var_dump($a[0][0] + $c[0]); ?>

BTW, I'm not against the feature, I'm against the implementation.

It's just can't be committed in current state.

Thanks. Dmitry.

________________________________
From: Christoph M. Becker <cmbecker69@gmx.de>
Sent: Thursday, August 25, 2016 2:49:51 PM
To: David Walker; PHP internals
Subject: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess

On 16.08.2016 at 17:55, David Walker wrote:

> I raised this concept a couple weeks ago to a couple +1's.  Discussion was
> held mostly upon the PR [1], and I went through and documented within the
> RFC [2].  I'd like to go ahead and open up the RFC to voting to the scope
> that it is written.
>
> [1] https://github.com/php/php-src/pull/2031
> [2] https://wiki.php.net/rfc/notice-for-non-valid-array-container

For the record, the RFC rightly claims:

| The default behavior, of a silent NULL return, is not correctly
| defined in the Array Documentation however is noted in a comment

I have documented this behavior now[3], and removed the note, which was
not quite correct, because it claimed that TRUE would be returned when
array dereferencing NULL, bool or int.

[3] <http://svn.php.net/viewvc?view=revision&revision=339937>

--
Christoph M. Becker



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Marco Pivetta

10 years ago

Hi Dmitry,

On 31 Aug 2016 8:37 a.m., "Dmitry Stogov" <dmitry@zend.com> wrote:

>
> I vote NO, because the implementation introduces more problems than

intents to fix.

>
> For example the following code starts to throw exception:
>
>
> <?php $a = [null]; $c = null; var_dump($a[0][0] + $c[0]); ?>

Isn't that the point of this RFC?
I would expect this code to only ever work by accident.

Dmitry Stogov

10 years ago

no. if you would try the proposed PR with this code, you would see:

Fatal error: Uncaught Error: Unsupported operand types

________________________________
From: Marco Pivetta <ocramius@gmail.com>
Sent: Wednesday, August 31, 2016 10:10:23 AM
To: Dmitry Stogov
Cc: Christoph M. Becker; PHP Internals List; Nikita Popov; David Walker
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess

Hi Dmitry,

On 31 Aug 2016 8:37 a.m., "Dmitry Stogov" <dmitry@zend.com<mailto:dmitry@zend.com>> wrote:

>
> I vote NO, because the implementation introduces more problems than intents to fix.
>
> For example the following code starts to throw exception:
>
>
> <?php $a = [null]; $c = null; var_dump($a[0][0] + $c[0]); ?>

Isn't that the point of this RFC?
I would expect this code to only ever work by accident.

Marco Pivetta

10 years ago

Ah, thanks, I thought it was silently passing :-)

On 31 Aug 2016 12:10 p.m., "Dmitry Stogov" <dmitry@zend.com> wrote:

Christoph Becker

10 years ago

On 31.08.2016 at 12:10, Dmitry Stogov wrote:

> no. if you would try the proposed PR with this code, you would see:
>
>
> Fatal error: Uncaught Error: Unsupported operand types

I get the following behavior against PR #1269:

$ sapi/cli/php -n -d error_reporting=-1 -r "\$a = [null]; \$c = null;
var_dump(\$a[0][0] + \$c[0]);"

Notice: Trying to get index of a non-array in Command line code on line 1

Notice: Trying to get index of a non-array in Command line code on line 1
int(0)

Cheers!

David Walker

10 years ago

I too get Dmitry's result.  As the left hand side is an error-zval, and the
right hand is null, it explodes.  Yes, the hackish way I try and resolve
things was to check opcodes around the current one, which I should have
thought in the case of addition wouldn't have been valid.  The entire goal
of the RFC was to prevent warning for obvious results (as it specifies on
long string of accesses).  One, thought about and ignored by me, aspect to
the RFC was the concept of a null entity.  Wherein any array access on null
would result with null.  I believe this could result in resolving many of
the headaches I'm attempting to resolve by managing a null-return from
array access as a literal null, or unknown cast to null.

On Wed, Aug 31, 2016 at 4:36 AM Christoph M. Becker <cmbecker69@gmx.de>
wrote:

David Walker

10 years ago

On Wed, Aug 31, 2016 at 7:48 AM David Walker <dave@mudsite.com> wrote:

> I too get Dmitry's result.  As the left hand side is an error-zval, and
> the right hand is null, it explodes.  Yes, the hackish way I try and
> resolve things was to check opcodes around the current one, which I should
> have thought in the case of addition wouldn't have been valid.  The entire
> goal of the RFC was to prevent warning for obvious results (as it specifies
> on long string of accesses).  One, thought about and ignored by me, aspect
> to the RFC was the concept of a null entity.  Wherein any array access on
> null would result with null.  I believe this could result in resolving many
> of the headaches I'm attempting to resolve by managing a null-return from
> array access as a literal null, or unknown cast to null.
>
> On Wed, Aug 31, 2016 at 4:36 AM Christoph M. Becker <cmbecker69@gmx.de>
> wrote:
>
>> On 31.08.2016 at 12:10, Dmitry Stogov wrote:
>>
>> > no. if you would try the proposed PR with this code, you would see:
>> >
>> >
>> > Fatal error: Uncaught Error: Unsupported operand types
>>
>> I get the following behavior against PR #1269:
>>
>> $ sapi/cli/php -n -d error_reporting=-1 -r "\$a = [null]; \$c = null;
>> var_dump(\$a[0][0] + \$c[0]);"
>>
>> Notice: Trying to get index of a non-array in Command line code on line 1
>>
>> Notice: Trying to get index of a non-array in Command line code on line 1
>> int(0)
>>
>> Cheers!
>>
>> > ________________________________
>> > From: Marco Pivetta <ocramius@gmail.com>
>> > Sent: Wednesday, August 31, 2016 10:10:23 AM
>> > To: Dmitry Stogov
>> > Cc: Christoph M. Becker; PHP Internals List; Nikita Popov; David Walker
>> > Subject: Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container
>> read-adccess
>> >
>> >
>> > Hi Dmitry,
>> >
>> > On 31 Aug 2016 8:37 a.m., "Dmitry Stogov" <dmitry@zend.com<mailto:
>> dmitry@zend.com>> wrote:
>> >>
>> >> I vote NO, because the implementation introduces more problems than
>> intents to fix.
>> >>
>> >> For example the following code starts to throw exception:
>> >>
>> >>
>> >> <?php $a = [null]; $c = null; var_dump($a[0][0] + $c[0]); ?>
>> >
>> > Isn't that the point of this RFC?
>> > I would expect this code to only ever work by accident.
>> >
>>
>

Apologies in advance for the toppost.  Gmail is the bane of my existence in
regards to mailing lists.

David Walker

10 years ago

On Wed, Aug 31, 2016 at 7:49 AM David Walker <dave@mudsite.com> wrote:

> On Wed, Aug 31, 2016 at 7:48 AM David Walker <dave@mudsite.com> wrote:
>
>> I too get Dmitry's result.  As the left hand side is an error-zval, and
>> the right hand is null, it explodes.  Yes, the hackish way I try and
>> resolve things was to check opcodes around the current one, which I should
>> have thought in the case of addition wouldn't have been valid.  The entire
>> goal of the RFC was to prevent warning for obvious results (as it specifies
>> on long string of accesses).  One, thought about and ignored by me, aspect
>> to the RFC was the concept of a null entity.  Wherein any array access on
>> null would result with null.  I believe this could result in resolving many
>> of the headaches I'm attempting to resolve by managing a null-return from
>> array access as a literal null, or unknown cast to null.
>>
>> On Wed, Aug 31, 2016 at 4:36 AM Christoph M. Becker <cmbecker69@gmx.de>
>> wrote:
>>
>>> On 31.08.2016 at 12:10, Dmitry Stogov wrote:
>>>
>>> > no. if you would try the proposed PR with this code, you would see:
>>> >
>>> >
>>> > Fatal error: Uncaught Error: Unsupported operand types
>>>
>>> I get the following behavior against PR #1269:
>>>
>>> $ sapi/cli/php -n -d error_reporting=-1 -r "\$a = [null]; \$c = null;
>>> var_dump(\$a[0][0] + \$c[0]);"
>>>
>>> Notice: Trying to get index of a non-array in Command line code on line 1
>>>
>>> Notice: Trying to get index of a non-array in Command line code on line 1
>>> int(0)
>>>
>>> Cheers!
>>>
>>> > ________________________________
>>> > From: Marco Pivetta <ocramius@gmail.com>
>>> > Sent: Wednesday, August 31, 2016 10:10:23 AM
>>> > To: Dmitry Stogov
>>> > Cc: Christoph M. Becker; PHP Internals List; Nikita Popov; David Walker
>>> > Subject: Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container
>>> read-adccess
>>> >
>>> >
>>> > Hi Dmitry,
>>> >
>>> > On 31 Aug 2016 8:37 a.m., "Dmitry Stogov" <dmitry@zend.com<mailto:
>>> dmitry@zend.com>> wrote:
>>> >>
>>> >> I vote NO, because the implementation introduces more problems than
>>> intents to fix.
>>> >>
>>> >> For example the following code starts to throw exception:
>>> >>
>>> >>
>>> >> <?php $a = [null]; $c = null; var_dump($a[0][0] + $c[0]); ?>
>>> >
>>> > Isn't that the point of this RFC?
>>> > I would expect this code to only ever work by accident.
>>> >
>>>
>>
>
>
>
> Apologies in advance for the toppost.  Gmail is the bane of my existence
> in regards to mailing lists.
>

Hi all,

As of now, the scheduled time the vote is to close, the RFC stands 19-4
(accepted).  Given this is my first solo RFC, I'm not really sure protocol
to go from here.  Dmitry does raise that the implementation I put forward
maybe a bit hackish compared to what someone much more knowledgeable could
implement.  So I'm not certain if the RFC should be deemed accepted, or,
fall into the howto section 7(3) and go back to discussion (if it is
considered a serious issue).

Direction appreciated.

--
Dave

Bishop Bettini

10 years ago

> On Wed, Aug 31, 2016 at 7:49 AM David Walker <dave@mudsite.com> wrote:
> Hi all,
>
> As of now, the scheduled time the vote is to close, the RFC stands 19-4
> (accepted).  Given this is my first solo RFC, I'm not really sure protocol
> to go from here.  Dmitry does raise that the implementation I put forward
> maybe a bit hackish compared to what someone much more knowledgeable could
> implement.  So I'm not certain if the RFC should be deemed accepted, or,
> fall into the howto section 7(3) and go back to discussion (if it is
> considered a serious issue).
>
> Direction appreciated.

The idea is approved. It still has to be an accepted PR. So, take the
dissenting feedback as a guide to improve the test coverage and
implementation. Possibly try the null coalesce approach as an alternative
implementation: that might make it all simpler! If you get stuck, bounce
the list a question. We're here to help.

Dmitry Stogov

10 years ago

Hi David,


I would propose to cancel voting and restart it when the good implementation is found.

Otherwise, people may rise their hands for something that can't be implemented in good enough way.


Thanks. Dmitry.


________________________________
From: David Walker <dave@mudsite.com>
Sent: Thursday, September 1, 2016 3:05:44 AM
To: Christoph M. Becker; Dmitry Stogov; Marco Pivetta
Cc: PHP Internals List; Nikita Popov
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess

On Wed, Aug 31, 2016 at 7:49 AM David Walker <dave@mudsite.com<mailto:dave@mudsite.com>> wrote:
On Wed, Aug 31, 2016 at 7:48 AM David Walker <dave@mudsite.com<mailto:dave@mudsite.com>> wrote:
I too get Dmitry's result.  As the left hand side is an error-zval, and the right hand is null, it explodes.  Yes, the hackish way I try and resolve things was to check opcodes around the current one, which I should have thought in the case of addition wouldn't have been valid.  The entire goal of the RFC was to prevent warning for obvious results (as it specifies on long string of accesses).  One, thought about and ignored by me, aspect to the RFC was the concept of a null entity.  Wherein any array access on null would result with null.  I believe this could result in resolving many of the headaches I'm attempting to resolve by managing a null-return from array access as a literal null, or unknown cast to null.

On Wed, Aug 31, 2016 at 4:36 AM Christoph M. Becker <cmbecker69@gmx.de<mailto:cmbecker69@gmx.de>> wrote:
On 31.08.2016 at 12:10, Dmitry Stogov wrote:

> no. if you would try the proposed PR with this code, you would see:
>
>
> Fatal error: Uncaught Error: Unsupported operand types

I get the following behavior against PR #1269:

$ sapi/cli/php -n -d error_reporting=-1 -r "\$a = [null]; \$c = null;
var_dump(\$a[0][0] + \$c[0]);"

Notice: Trying to get index of a non-array in Command line code on line 1

Notice: Trying to get index of a non-array in Command line code on line 1
int(0)

Cheers!

> ________________________________
> From: Marco Pivetta <ocramius@gmail.com<mailto:ocramius@gmail.com>>
> Sent: Wednesday, August 31, 2016 10:10:23 AM
> To: Dmitry Stogov
> Cc: Christoph M. Becker; PHP Internals List; Nikita Popov; David Walker
> Subject: Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess
>
>
> Hi Dmitry,
>
> On 31 Aug 2016 8:37 a.m., "Dmitry Stogov" <dmitry@zend.com<mailto:dmitry@zend.com><mailto:dmitry@zend.com<mailto:dmitry@zend.com>>> wrote:
>>
>> I vote NO, because the implementation introduces more problems than intents to fix.
>>
>> For example the following code starts to throw exception:
>>
>>
>> <?php $a = [null]; $c = null; var_dump($a[0][0] + $c[0]); ?>
>
> Isn't that the point of this RFC?
> I would expect this code to only ever work by accident.
>

Apologies in advance for the toppost.  Gmail is the bane of my existence in regards to mailing lists.

Hi all,

As of now, the scheduled time the vote is to close, the RFC stands 19-4 (accepted).  Given this is my first solo RFC, I'm not really sure protocol to go from here.  Dmitry does raise that the implementation I put forward maybe a bit hackish compared to what someone much more knowledgeable could implement.  So I'm not certain if the RFC should be deemed accepted, or, fall into the howto section 7(3) and go back to discussion (if it is considered a serious issue).

Direction appreciated.

--
Dave

Niklas Keller

10 years ago

Dmitry Stogov <dmitry@zend.com> schrieb am Mi., 31. Aug. 2016, 08:37:

> I vote NO, because the implementation introduces more problems than
> intents to fix.
>
> For example the following code starts to throw exception:
>
>
> <?php $a = [null]; $c = null; var_dump($a[0][0] + $c[0]); ?>
>

Array access on null should always throw IMO.

BTW, I'm not against the feature, I'm against the implementation.

>
> It's just can't be committed in current state.

I think we vote on features, not implementations. Therefore you should
probably have voted yes.

Thanks. Dmitry.

Dmitry Stogov

10 years ago

RFC proposes to emit warning, but the provided code throws unrelated "Unsupported operand types" exception.

I see, that after few weeks of work, the implementation (just few lines of C code) is still hackish and incomplete.

This makes me think that, the feature can't be cleanly implemented, and I vote against it.

Thanks. Dmitry.

________________________________
From: Niklas Keller <me@kelunik.com>
Sent: Wednesday, August 31, 2016 10:58:16 AM
To: Dmitry Stogov; Christoph M. Becker; David Walker; PHP internals
Cc: Nikita Popov
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess

Dmitry Stogov <dmitry@zend.com<mailto:dmitry@zend.com>> schrieb am Mi., 31. Aug. 2016, 08:37:
I vote NO, because the implementation introduces more problems than intents to fix.

For example the following code starts to throw exception:

<?php $a = [null]; $c = null; var_dump($a[0][0] + $c[0]); ?>

Array access on null should always throw IMO.

BTW, I'm not against the feature, I'm against the implementation.

It's just can't be committed in current state.

I think we vote on features, not implementations. Therefore you should probably have voted yes.

Thanks. Dmitry.

________________________________
From: Christoph M. Becker <cmbecker69@gmx.de<mailto:cmbecker69@gmx.de>>
Sent: Thursday, August 25, 2016 2:49:51 PM
To: David Walker; PHP internals
Subject: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess

On 16.08.2016 at 17:55, David Walker wrote:

> I raised this concept a couple weeks ago to a couple +1's.  Discussion was
> held mostly upon the PR [1], and I went through and documented within the
> RFC [2].  I'd like to go ahead and open up the RFC to voting to the scope
> that it is written.
>
> [1] https://github.com/php/php-src/pull/2031
> [2] https://wiki.php.net/rfc/notice-for-non-valid-array-container

For the record, the RFC rightly claims:

| The default behavior, of a silent NULL return, is not correctly
| defined in the Array Documentation however is noted in a comment

I have documented this behavior now[3], and removed the note, which was
not quite correct, because it claimed that TRUE would be returned when
array dereferencing NULL, bool or int.

[3] <http://svn.php.net/viewvc?view=revision&revision=339937>

--
Christoph M. Becker



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php