Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

When you put an @ infront of a function or a language construct in this case all of the code performed by the function effectively has an error level of 0. Meaning that your error_reporting(0) inside y.php is not necessary as the error reporting is already at 0.

I think you mis-understood this problem.

The error_level reporting set in y.php is necessary here as it is where the runtime value of error_reporting is set.

The problem is, when using the @ syntax on the include, the runtime setting for error_reporting in the included file is ignored in the scope of the parent script ( z.php ) and has to set again in z.php once y.php has been parsed even though y.php set the error_reporting.

What I do expect to see here is a setting, any setting in the included file, to not only be available in the scope of the parent, but to also overwrite any previous value that existed prior to the include event:

1) You request a script from a server ( z.php ).  At This point error_reporting is set at whatever the servers default php.ini setting is.

2) z.php then includes y.php with the @ syntax.

3) y.php loads any required files and functions, sets processing defaults, etc... This includes setting a runtime error_reporting value to be used by all included/parsed scripts from this point on.

4) y.php returns to z.php after successful parsing, however the runtime value of error_reporting set in y.php is NOT the value that when returning to z.php.

My understanding of the docs is when using the @ syntax, you temporarily override the current value of error_reporting for that function/include. Once parsed, the error level is return to it's original setting.

However this is not the case here because you are getting two different results, one incorrect result when using the @ syntax, and the expected result when not using the @ syntax.

To summarize:

1) Using @include or @require when the file being included is expected to set a runtime error_report value, that value is NOT available in the scope of the parent script

2) When NOT using the @ syntax, the included file successfully set's the error_reporting and that value IS available in the scope of the parent script.

Just don't mix @ with language constructs.
(and usually when you need to use @ there's something wrong with your script/code logic)

The problem isn't with the script perse, the '@' in this instance is being used suppress "possible" errors that would then reveal what some consider sensitive information to hackers regarding directory structure on the server.

I think the point to take away from this is there is a discrepency in the behavior when using '@' on includes.  In short, one would expect the behavior to be the same regardless of how you write the include ( with or without the '@' ), however it is not.