ID: 26006 Comment by: mpn at illearth dot net Reported By: gms08701 at yahoo dot com Status: Bogus Bug Type: *General Issues Operating System: FreeBSD 4.8-RELEASE-p10 PHP Version: 4.3.3 New Comment:
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. Previous Comments: ------------------------------------------------------------------------ [2003-11-17 18:27:44] [EMAIL PROTECTED] Just don't mix @ with language constructs. (and usually when you need to use @ there's something wrong with your script/code logic) ------------------------------------------------------------------------ [2003-11-12 10:34:18] mpn at illearth dot net 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. ------------------------------------------------------------------------ [2003-10-27 22:41:13] [EMAIL PROTECTED] 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. ------------------------------------------------------------------------ [2003-10-27 11:07:49] gms08701 at yahoo dot com Description: ------------ To my knowledge, when using @ at a function/variable/etc, it sets error_reporting to 0 at that instance, and return, to its previous state, after that instance. Unfortunately, after the instance of @, instead of returning to what it was set at previously, it returns to what is set in php.ini Reproduce code: --------------- --y.php-- <?php // error_reporting is currently at E_ALL (set from php.ini) // Set error_reporting to 0 error_reporting(0); // Returns 0 here var_dump(error_reporting()); ?> --z.php-- <?php @require('./y.php'); // This returns 2047 (E_ALL) var_dump(error_reporting()); ?> Expected result: ---------------- Its expected that z.php should return 0 from the var_dump(), where it inherits its error_reporting value from y.php, but is currently returning 2047 (E_ALL) When I remove '@' from require('./y.php'); in z.php, it then works correctly. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=26006&edit=1
