cvs: phpdoc /en/security errors.xml

sfox Mon Jan 31 07:53:29 2005 EDT Modified files: /phpdoc/en/security errors.xml Log: Getting rid of the E_NONE myth, and also incorporating a user note. http://cvs.php.net/diff.php/phpdoc/en/security/errors.xml?r1=1.6&r2=1.7&ty=u Index: phpdoc/en/security/errors.xml diff -u phpdoc/en/security/errors.xml:1.6 phpdoc/en/security/errors.xml:1.7 --- phpdoc/en/security/errors.xml:1.6 Thu Aug 12 21:00:48 2004 +++ phpdoc/en/security/errors.xml Mon Jan 31 07:53:28 2005 @@ -1,5 +1,5 @@ <?xml version="1.0" encoding="iso-8859-1"?> -<!-- $Revision: 1.6 $ --> +<!-- $Revision: 1.7 $ --> <!-- splitted from ./index.xml, last change in rev 1.66 --> <chapter id="security.errors"> <title>Error Reporting</title> @@ -100,7 +100,13 @@ By testing your code, prior to deployment, with E_ALL, you can quickly find areas where your variables may be open to poisoning or modification in other ways. Once you are ready for deployment, - by using E_NONE, you insulate your code from probing. + you should either disable error reporting completely by setting + <function>error_reporting</function> to 0, or turn off the error + display using the &php.ini; option <literal>display_errors</literal>, + to insulate your code from probing. If you choose to do the latter, + you should also define the path to your log file using the + <literal>error_log</literal> ini directive, and turn + <literal>log_errors</literal> on. <example> <title>Finding dangerous variables with E_ALL</title> <programlisting role="php">