Rasmus Lerdorf <[EMAIL PROTECTED]> writes: > You need a php.ini file to reproduce the problem.
OK, thanks. With everybody's help I reproduced the problem. It turns out to be a portability bug in Zend/zend_ini_parser.y. That grammar uses the character constant '\0' as a token. POSIX says that the behavior is undefined in this case. See <http://www.opengroup.org/onlinepubs/007904975/utilities/yacc.html>, section "Lexical Structure of the Grammar", which says "The application shall ensure that the NUL character is not used in grammar rules or literals." This prohibits grammars from using '\0' tokens. I suspect that earlier versions of Bison silently ignored any grammar rules containing '\0' tokens, but newer versions cause them to make the generated parser dump core. Both behaviors conform to POSIX, but obviously it'd be better if Bison issued a diagnostic when it sees such tokens. I'll install a fix to Bison to do that. Here is a patch to PHP to fix the PHP bug. This patch is relative to php5, but the bug is php4 as well. I've submitted this patch to bugs.php.net (it's PHP bug #25770). 2003-10-06 Paul Eggert <[EMAIL PROTECTED]> * Zend/zend_ini_parser.y: This fixes PHP bugs #25770 and #21159. Index: Zend/zend_ini_parser.y =================================================================== RCS file: /repository/ZendEngine2/zend_ini_parser.y,v retrieving revision 1.24 diff -p -u -r1.24 zend_ini_parser.y --- Zend/zend_ini_parser.y 10 Jun 2003 20:03:25 -0000 1.24 +++ Zend/zend_ini_parser.y 7 Oct 2003 06:55:36 -0000 @@ -213,7 +213,6 @@ string_or_value: | CFG_TRUE { $$ = $1; } | CFG_FALSE { $$ = $1; } | '\n' { $$.value.str.val = strdup(""); $$.value.str.len=0; $$.type = IS_STRING; } - | '\0' { $$.value.str.val = strdup(""); $$.value.str.len=0; $$.type = IS_STRING; } ; expr: -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
