New by reference not giving warning

Question

All over the web[1][2][3], it says that since PHP 5.0.0 "assigning the return value of new by reference" gives a E_DEPRECATED or E_STRICT depending on your php version (E_DEPRECATED didn't exist until 5.3, so it was E_STRICT before that).

As such it is my understanding that this code should give such a warning:

error_reporting(E_ALL | E_STRICT);

class A
{
}

$a =& new A();

However, I have tried this on two completely different servers (one running PHP 5.3 and one running PHP 5.2) and neither is actually giving any message! What's going on? Is my understanding incorrect or is something strange going on on those two servers?

(I do also think it is strange that this is deprecated, seeing that $a = null; $b =& $a; $b = new A(); does not do the same as $a = null; $b =& $a; $b =& new A();, but that's only a part of the question if I misunderstood what is deprecated...)

Strangely, I only get this error if I run this on `phpsh`, `PHP Deprecated: Assigning the return value of new by reference is deprecated in /Library/Python/2.7/site-packages/phpsh/phpsh.php(578) : eval()'d code on line 1`, but not if I run it directly from cli. — Dogbert, Nov 06 '12 at 14:41
@Dogbert: That's strange indeed. I have only tried it as served from external Apache servers myself, but when I have the time I'll look into running it from the commandline and `phpsh` myself — Jasper, Nov 06 '12 at 14:56
It wouldn't at all surprise me if the problem here lies elsewhere: try setting `E_ALL | E_STRICT` in your php.ini directly, don't forget to change the php-cli.ini, too, if you're running this code on the command line. Also double check if the errors aren't hidden by doing an `ini_set('display_errors',1);`. Also, if you're running this on a windows box, there have been [some bugs](https://bugs.php.net/bug.php?id=46326) with this in the past — Elias Van Ootegem, Nov 06 '12 at 15:03
@Dogbert: That's because the cli has a different ini file, and you're best off by using a hash-bang with the `-n` flag: `#!/local/bin/php -n`, to run the script with the default setup — Elias Van Ootegem, Nov 06 '12 at 15:05
@EliasVanOotegem: Not having easy access to `php.ini` in my current setups, I set it in my `.htaccess` instead. And in fact, it turns out you were correct, these warnings are generated before anything is executed. If you'll answer, I'll accept. — Jasper, Nov 06 '12 at 17:02
@Jasper: done. Interesting question, though... I'm going to try out a couple more things :) — Elias Van Ootegem, Nov 06 '12 at 17:17
@EliasVanOotegem: Thanks. In fact I knew the difference between the two ways of turning the error reporting on. I just completely assumed that these things would come up run-time. I suppose if it isn't type-related it and thus *can* be reported at compile time, it will be. — Jasper, Nov 06 '12 at 17:24

score 2 · Accepted Answer · answered Nov 06 '12 at 17:15

In response to the OP, this comment pointed him in the right direction:

It wouldn't at all surprise me if the problem here lies elsewhere: try setting E_ALL | E_STRICT in your php.ini directly, don't forget to change the php-cli.ini, too, if you're running this code on the command line.
Also double check if the errors aren't hidden by doing an ini_set('display_errors',1);1. If you're running this on a windows box, there have been some bugs with this in the past.

Since the OP also pointed out that the warnings were generated before any code got executed, I had a hunch, that the expected warnings are being raised at compile-time, rather then runtime, so I had another look at the docs. There, I found this big red-box note, which confirmed my suspicions:

Most of E_STRICT errors are evaluated at the compile time thus such errors are not reported in the file where error_reporting is enhanced to include E_STRICT errors (and vice versa).

Since version 5 PHP is effectively a "compiled" language (similar to Java, the code is compiled to Zend Bytecode). When the Zend-engine compiles code with errors that are issued at compiled time, an in-script error_reporting call has no effect on weather or not these errors are reported: the error_reporting call applies only to the runtime errors/warnings.
Perhaps this: error_reporting(E_ALL | E_STRICT | E_COMPILE_ERROR); is worth a look, too

Bottom line:
Set the error reporting in the php.ini files whenever you can.

In fact, the point that the errors are made before any code is executed (which is another way of saying compile-time) was a conclusion I drew from the fact that setting the `error_reporting` from the script didn't work and setting it externally did work. Of course, the code also showed it, but at that point I was expecting the errors at the top if showing up at all. — Jasper, Nov 06 '12 at 17:22
@Jasper, I assumed you knew about compile- vs runtime, but it's something not everybody as aware of, that's why I included that distinction in my answer, so this is mostly meant to inform others. Your problem, as you know all too well by now, was just down to the .ini file deals with the settings if the Zend engine from start to finish, `error_reporting` only overrides those settings once the code has been compiled and is ready to run. I just figured not everybody would have found that sufficient as an answer ;-P... anyway, good question: I found out a couple of new things along the way, too — Elias Van Ootegem, Nov 06 '12 at 18:20
It's good that you included it in your answer and that wasn't what I was talking about, really. What I was talking about was the phrasing of `since the OP also pointed out [..]`. Yeah, I can be picky at times. But never mind, it's close enough to the truth :D — Jasper, Nov 06 '12 at 19:08

New by reference not giving warning

1 Answers1