Description: ------------ If an statement is prepended with the suppression operator @ it is still logged by the daemon.

That's expected behavior because the error is always still fired. It's just silenced by PHP. But since System_Daemon catches errors, yeah they get logged. So is that a real bug? I think not. The use of isset(), empty(), coding with notices on And then logging errors, is more of an instrument against bugs in my humble opinion. If you have another view on that, there is one solution we could implement: http://nl.php.net/manual/en/function.set-error-handler.php#29315 But I think that would need to be optional in any case. What do you think?

Well, I marked it as a feature/change request because I wasn't sure it was a bug either :) I agree that checking variables with isset and empty are good prevention methods, but some functions such as socket_accept generate warnings when the socket is busy and there is no way to check if the socket is busy. It sucks, but it's the way it is. If you have a server checking a socket for new connections in a loop and you want it non-blocking, you're going to get these warnings unless you suppress them. The patch I submitted simply returns from phpErrors if error_reporting() returns 0, which it will if the statement that caused the error was suppressed.

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. I did not notice the patch, sorry for that. What you say in your reply makes sense to me. I've committed the patch and it will be in the next release. Thanks a lot!