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