php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #46602 Change: Accessing by [] or {} to variables of other type silently returns NULL
Submitted: 2008-11-18 08:55 UTC Modified: 2013-07-30 03:21 UTC
Votes:5
Avg. Score:3.8 ± 1.5
Reproduced:3 of 5 (60.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: bugs dot php dot net-V29nHf1_z-nsp at cvogt dot org Assigned:
Status: Wont fix Package: *General Issues
PHP Version: 5.2.6 OS:
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: bugs dot php dot net-V29nHf1_z-nsp at cvogt dot org
New email:
PHP Version: OS:

 

 [2008-11-18 08:55 UTC] bugs dot php dot net-V29nHf1_z-nsp at cvogt dot org 
Description:
------------
As http://bugs.php.net/bug.php?id=41195 requested http://de2.php.net/language.types.string now mentions, accessing other types than strings, arrays or objects using the [] operator silently returns NULL.

This behavior hides bugs. There is no sensible reason to use [] on a other types than mentioned, so it should result in an error. It would make sense to trigger an E_NOTICE. However, to be gentle to backwards compatibility it could also trigger an E_STRICT instead.

The "expected result" below is only an example of a possible message.

Reproduce code:
---------------
$o = NULL;
var_dump($o[0]);

Expected result:
----------------
Notice: Undefined offset: 0 for value of type NULL
NULL

Actual result:
--------------
NULL

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-07-30 03:21 UTC] yohgaki@php.net
-Status: Open +Status: Wont fix -Package: Feature/Change Request +Package: *General Issues
 [2013-07-30 03:21 UTC] yohgaki@php.net 
I agree that raising error may help debugging.
However, this behavior is not likely to be changed.

1. It breaks many codes.
2. Introducing E_DEBUG or like will create confusion.

Feel free to bring this issue to internals ML, if anyone feel this change in 
appropriate.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sat May 03 15:01:28 2025 UTC