The assertion "... Seems that PHP cannot redirect 'Call to undefined function' errors to a custom error
handler..." is incorrect.

This seems to be a problem w/ the person reporting the bug *not* using the error_reporting() function, as it is clearly noted in the manual example, changing the code to read:

<?php
define (ERROR,E_USER_WARNING);
define (WARNING,E_USER_NOTICE); 

// set the error reporting level for this script
error_reporting (FATAL | ERROR | WARNING);

// Define a simple error handler
function error_handler ($level, $message, $file, $line, $context) {
echo "An error of level $level was generated in file $file on line $line.
\nThe error message was: $message \nThe following variables were set in the
scope that the error occurred in: <blockquote> ";
print_r ($context);
print "\n</blockquote>";
}
// Set the error handler to the error_handler() function
set_error_handler ('error_handler');
trigger_error ("Some other error"); 

whatever();
?>

The output is:

An error of level 1024 was generated in file bugtest.php on line 20. 


The error message was: Some other error
The following variables were set in the
scope that the error occurred in: <blockquote> 
Array (
    [PWD] => /tmp
[... snip ...]
    [_] => /usr/local/bin/php
    [PHP_SELF] =>
    [argv] => Array
        (
            [0] => bugtest.php
        )
 
    [argc] => 1
    [HTTP_POST_VARS] => Array
        (
        )
    [HTTP_GET_VARS] => Array
[...snip...]

</blockquote> 

This was tested with 4.0.6 on RH 7.1, more information is requested from the person reporting the bug, before it is reclassified as bogus.

My mistake, did not understood the bug report correctly.

More testing shows that calls to undefined functions do 
not generate an error level that can be catched by the error handling mechanism. Not even when using:

error_reporting(E_ALL);

which just aborts execution of the script and gives the msg:

<b>Fatal error</b>:  Call to undefined function:  whatever() in <b>junk.php</b> on line <b>24</b><br>

whereas when using:

error_reporting(E_CORE);

just "eats up" the error (i.e. no fatal error msg is generated by the interpreter), and the error handling function does not have time to do anything, so the script aborts w/o any output.

Two issues need to be addressed:

1) The inconsitent behavior of E_CORE vs E_ALL (PHP 4.0.6), in view of the fact the E_ALL includes E_CORE (as per Zend/zend_errors.h)

2) Whether is desirable to allow catching of fatal errors using the set_error_handler() and error_reporting() functions

If the answer to (2) is no, then this should be clarified in the manual.

Using: 

error_reporting("E_ERROR"); 

does not work (same result as E_ALL), even though in Zend/zend_execute.c that is the error level raised. 

In Zend/zend.c the zend_error() function hands the error to zend_error_cb, which points to one of the utility functions created during zend_startup() (called in main/main.c)

I cannot track the chain down more, my C is very rusty.

Encountered the error "eat up" too... The description was brief, not to be flamed for flooding or boring :)

I believe that's just a simple bug somewhere in the routines...
Can't wait to see it fixed, while those fatals damage my web layout.

regards

Works fine for me with PHP 4.3.0-dev, please try the latest non-stable snapshot from snaps.php.net and reopen if it is not fixed for you.

Derick