Fix #64194: NULL variable (and scalars) do not give error when trying to use as array

[AllenJB]

No description provided.

[smalyshev]

Putting line numbers in tests is usually not a very good idea, as adding comments, etc. will break the test. It should be done only if line number is important.

[smalyshev]

This didn't happen in 5.x so probably needs an RFC.

[AllenJB]

I'll fix the test line numbers issue (tho if you ask me, the line on which an error / notice occurs is always important).

I'm currently stuck trying to fix the mysqli_fork.phpt failure (I could just silence the notice or add it to expected output, but IMO the code should be fixed to not produce the notice in the first place). Alas the forking is making my tired brain hurt right now, so I'm going to take another look tomorrow.

[morrisonlevi]

I think the current behavior with null is intended so that multi-dimensional arrays can be used in isset without worries. In other words, isset($some[$deep][$maybe][$non][$existing][$thing]) will not error.

[smalyshev]

Isset should never produce any errors due to something not existing, so if the patch does that (I haven't checked yet) it is not acceptable.

[AllenJB]

Thanks for raising that case.I just double-checked and currently the following isset-deep-array-key case does produce a notice, however I can look into if this can be fixed (the similar case of trying to access deep properties on a non-object is currently silent for isset, so there should be a way to achieve this - I'll take a look at how that's achieved).

error_reporting(E_ALL);
$a = null;
$b = isset($a['foo']['bar']);

[AllenJB]

I believe I've fixed all the issues and Travis is now passing. Please let me know if there's any further issues.

[cmb69]

Allen, thanks for taking the time to cater to this issue. In my opinion, silently evaluating to NULL is an unfortunate behavior. I've written to the internals mailing list to get more attention.

[datibbaw]

Nice. I had attempted to fix this before, but because I didn't check for BP_VAR_IS I encountered issues with uses of each() and gave up; if I had known this before, we could've had it for 7.0 =S

[yohgaki]

This patch raises error rather than exception.
Something like this is preferred, but "Uncaught EngineException" might be too severe...

[yohgaki@dev github-php-src]$ php

[AllenJB]

The behaviour chosen mirrors that used for undefined properties on scalars / nulls, both in using a notice rather than an error/EngineException (which also reduces the BC implications, as existing code will continue to work as expected), and the behaviour of multiple notices for deep references (for the behaviour with properties, see http://3v4l.org/cYocM )

I believe it's important to raise a notice for this case (both for NULL and other scalars) because it hilights potential bugs in the code where the developer was expecting to receive an array, but got something else (such a bug in my own code is what lead me to write this PR).

I also believe a notice (rather than error / exception) is most suitable because it allows people who wish to simply ignore this case to do so.

@datibbaw What were the issues you encountered with each()? Was it picked up by the existing PHP test suite? Can you provide an example the reproduces the issue? (I'd like to check this PR against it to ensure that a similar issue doesn't exist). TIA

[datibbaw]

@AllenJB Sure, my branch can be found here. The issue is that each() internally does something like $key = false[0]; $value = false[1];, so my branch would emit a warning at that point ... I don't think this happens with yours ;-)

[AllenJB]

I checked the behaviour of each() and it appears to be completely unaffected by this PR - it looks like it has its own handling for non-array values.

[AllenJB]

I've added tests that explicitly cover object properties and function return values, since they were brought up on internals.

Unsure why the travis build is failing here. It's passed on my branch.

[krakjoe]

As already pointed out, this requires an RFC.

Please start the RFC process with a discussion on internals and an RFC on the wiki so that this can move forward.

If no RFC materializes, eventually this will be closed.

[AllenJB]

An RFC was already accepted for this feature, but is mysteriously "pending implementation" despite 3 different PRs (including the proposed implementation), mentioned on the RFC itself, already existing for it: https://wiki.php.net/rfc/notice-for-non-valid-array-container

I did attempt to start the RFC prior to that RFC being proposed, but my request to internals for RFC karma on the wiki was ignored and I kind of lost interest after that.

[krakjoe]

@AllenJB we are the worst, sorry about that :)

If you want to request RFC karma again, I can grant you that now ...

I guess we need a discussion to pick an implementation ?

Would be good if someone familiar with the subject matter could start one (I only have cursory familiarity and have read about 200 pull requests in the last few days ... everything is a blur).

[nikic]

A PR for this change matching the RFC is in #2031, so I'll close this one. The PR hasn't been merged yet because there were some concerns around how the suppression of duplicate notices on nested accesses is handled.