Contributions to PHP

Manual: Safe Mode

Manual: DomNode->dump_node()

Manual: assert()

Manual: get_class_methods()

Manual: eval()

Manual: xml_parser_get_option()

Bug Reports

Google

Ongoing Bug Research (Unreported)

Manual: Safe Mode
This note has been removed from the manual since the documentation has been corrected, per my suggestion below. gk at proliberty dot com (27-Apr-2003 08:05) The documentation on safe_mode is wrong. It says: >When safe_mode is on, PHP checks to see if the owner of the current script matches the owner of the file to be operated on by a file function. In truth, it also checks the ownership of the current directory: directory ownership overrides file UID - i.e., if you own the directory, your script can read any files in the directory, regardless of file UID. Rasmus has confirmed that this is not a bug, it is by design. The documentation should be updated to reflect this.
Manual: DomNode->dump_node()
DomNode->dump_node() gk at proliberty dot com 10-Jan-2003 01:39 The first comment above is wrong, at least, now in PHP 4.3.0 Example: <?php $xml=<<<eot <node attr="test"><test>hi</test> </node> eot; $doc = domxml_open_mem($xml); $root=$doc->document_element(); //This will NOT work: //$nodeDump =$doc->dump_node($doc); //This works: $nodeDump =$doc->dump_node($root); echo htmlentities($nodeDump); ?>
Manual: assert()
assert() gk at proliberty dot com 26-Aug-2005 07:35 If you expect your code to be able to work well with other code, then you should not make any assumptions about the current state of assert_options() flags, prior to calling assert(): other code may disable ASSERT_ACTIVE, without you knowing it - this would render assert() useless! To avoid this, ALWAYS set assert_options() IMMEDIATELY before calling assert(), per the C++ paradigm for assertion usage: In one C++ source file, you can define and undefine NDEBUG multiple times, each time followed by #include <cassert>, to enable or disable the assert macro multiple times in the same source file. Here is how I workaround this issue in my PHP code: [see online manual]
Manual: get_class_methods()
"get_class_methods()" http://www.php.net/manual/en/function.get-class-methods.php gk at proliberty dot com 01-Jun-2003 05:16 It is important to note that get_class_methods($class) returns not only methods defined by $class but also the inherited methods. There does not appear to be any PHP function to determine which methods are inherited and which are defined explicitly by a class.
Manual: eval()
eval() This note has been removed from the manual since the documentation has been corrected. gk at proliberty dot com (11-Jun-2003 08:48) eval() returns FALSE if a fatal error occurs. For this reason, you should never return() a FALSE value from eval()'d code or else you will lose the distinction between FALSE and FATAL. Note also that if you have installed a custom error handler, with set_error_handler(), it will NOT be used to handle errors inside your eval() statement. You can call eval("set_error_handler('myErrorHandler'); //...") but Parse and other Fatal errors that NEVER are passed to a custom error handler will still always result in FALSE being returned from eval(). Sample code: <?php // FILE: test/test.php $x=eval(";"); echo "Default Return Value: "; if($x===FALSE) echo "FALSE\n"; if(is_null($x)) echo "NULL\n"; $x=eval("<?"); echo "Fatal Error Returns: "; if($x===FALSE) echo "FALSE\n"; if(is_null($x)) echo "NULL\n"; ?> OUTPUT: $ php test/test.php Default Return Value: NULL PHP Parse error: parse error in /usr/local/apache/htdocs/common/php/xmake_org/xobj/test/test.php(6) : eval()'d code on line 1 Fatal Error Returns: FALSE
Manual: xml_parser_get_option()
"xml_parser_get_option()" http://www.php.net/manual/en/function.xml-parser-get-option.php My manual notes submission appeared as follows: at proliberty dot com (28-Jun-2002 02:48) These 'undocumented' options don't work in linux either (PHP 4.2.1) yields: xml_parser_get_option: unknown option... with both: xml_parser_get_option ($parser,XML_OPTION_SKIP_TAGSTART); and xml_parser_get_option ($parser,XML_OPTION_SKIP_WHITE); Subsequently, this and all such similar reports were deleted from the manual, leaving the documentation incorrect. Three years later, I finally forced the issue to be re-opened and the bug was fixed. (see bug #34278).
Bug Reports
Bug #22839 Error messages go to STDOUT instead of STDERR http://bugs.php.net/22839 Status: Open My report: ... The behavior of PHP appears confused. PHP should offer two clearly separated output mechanisms to the programmer: 1. echo() - for sending 'normal' output to /dev/stdout 2. trigger_error() - for sending 'errors' to /dev/stderr In my case, I am running php scripts via cron. I always want to maintain a historical record, via error_log, but I also need cron to email any true errors immediately - I don't want to set error_log = /dev/stderr and lose the historical error_log record in order to accomplish this simple task that would be a no-brainer if my script was written in bash instead of php. Bug #34281 xml_set_processing_instruction_handler PI definition is wrong http://bugs.php.net/34281 Status: Closed (Fixed) Bug #34278 xml_parser_get_option manual fails to specify options causing E_WARNING http://bugs.php.net/34278 Status: Closed (Fixed) Bug #33430 auto_prepend_file not respected in command line environment http://bugs.php.net/33430 Status: Open Bug #24135 eval() documentation ignores FALSE return value from Fatal Errors http://bugs.php.net/24135 Status: Closed (Fixed) Bug #22844 text boolean ini options set with -d do not work (on/off) http://bugs.php.net/22844 Status: Closed (Fixed) Bug #22775 Fatal error from require() exits with status=0 http://bugs.php.net/22775 Status: Closed (Fixed) Bug #21891 Closing PHP tag and Newlines Revisted http://bugs.php.net/21891 Status: Wont fix Bug #15943 Viewing .phps Crashes with php.ini-recommended http://bugs.php.net/15943 Status: Closed (Fixed) Bug #36991 Passing illegal parameter to function should generate WARNING http://bugs.php.net/36991 Status: Bogus This is another case of poor design by PHP engineers: an example of why many do not consider PHP to be a 'serious' programming language. The argument against my feature request is that it is necessary to ignore a function definition's signature in order to allow func_get_args() and related functions to work. This argument is bogus actually: it could be the other way around - require the function definition to declare that it can accept variable number of arguments if variable arguments are to be allowed. With the current design, in order to functions to enforce a legal argument count, every function would have to call func_num_args and test. Better to have prototype enforcement be automatic and the use of func_get_args() be optional. In my opinion, the convenience of func_get_args() is less than the utility of general robustness and function prototype error-checking.
Google
Search: "gk at proliberty dot com" http://www.google.com/search?q=%22gk+at+proliberty+dot+com%22+site%3Aphp.net
Ongoing Bug Research (Unreported)
 BUG DESCRIPTION: Valid code has parsing problem PHP VERSION: 5.0.2 (cli) (built: Nov 23 2004 14:59:37) STEPS TO REPRODUCE: [greg@p3 include]$ php -r 'echo(empty(false));' RESULT: PHP Parse error: parse error, unexpected ')', expecting T_PAAMAYIM_NEKUDOTAYIM in Command line code on line 1 EXPECTED RESULT: 1 MANUAL SAYS: empty() returns FALSE if var has a non-empty or non-zero value. In otherwords, "", 0, "0", NULL, FALSE, array(), var $var;, and objects with empty properties, are all considered empty. TRUE is returned if var is empty. EXAMPLE: [greg@p3 include]$ php -r 'echo(true);' 1 T_PAAMAYIM_NEKUDOTAYIM: 'two colons' PAAMAYIM - twice NEKUDOTAYIM - colon
Last modified 07/18/07, 2:14 am; HTML auto-generated from text format by txt2html and XMake