Bug #55032 [Com]: Treating null, boolean and numbers as arrays does not trigger an error
Edit report at http://bugs.php.net/bug.php?id=55032&edit=1 ID: 55032 Comment by: cagret at gmail dot com Reported by:cagret at gmail dot com Summary:Treating null, boolean and numbers as arrays does not trigger an error Status: Duplicate Type: Bug Package:Variables related Operating System: Linux, Windows PHP Version:5.3.6 Block user comment: N Private report: N New Comment: What is the logic of keeping this bug as intended behavior? You do the opposite thing to undefined array indexes by showing an error, but here you do not do such thing. What is worse is that $array['no_such_key'] is a valid code even if there is no such key, but $true['asdf'] where $true is a boolean is just nonsense. Do you want some real life examples of why this behavior generates many of bugs in our code and makes our life harder? Do you even understand the problem? Previous Comments: ---- [2011-06-14 17:15:55] cagret at gmail dot com Thank you for reading my comment with understanding. We have an option to ignore/show E_NOTICE errors of undefined array indexes by setting error_reporting, why can't we have an option for not ignoring this behaviour? That could be easily fixed with no problems to backward compatibility, making it a behavior of E_STRICT or we could add an another E_ option for this. [2011-06-14 15:51:14] ahar...@php.net This is intended behaviour, per bug #41195. ---- [2011-06-13 19:14:44] cagret at gmail dot com If implementing it is a performance problem (can't think of any other reason why it still hasn't been fixed), then you could at least give us an option, for example a php.ini option "check_types" that would be checking for such error. That would allow us to enable this option on Developer machines during testings and hopefully we would catch and fix all of these errors before uploading the code to the Production machine. -------------------- [2011-06-11 02:19:47] cagret at gmail dot com Description: This bug is really annoying and generates many headeaches to millions of php developers. It's really hard to detect this bug sometimes, and that is because we have so much faith in PHP and we think that it's not possible that php would allow us to write such a nonsensical code and not throw an error, after all didn't we set the most strict error reporting you allow us to set? This example code should be self explanatory: Please fix it ASAP. Thank you for your time. -- Edit this bug report at http://bugs.php.net/bug.php?id=55032&edit=1
Bug #55032 [Com]: Treating null, boolean and numbers as arrays does not trigger an error
Edit report at http://bugs.php.net/bug.php?id=55032&edit=1 ID: 55032 Comment by: cagret at gmail dot com Reported by:cagret at gmail dot com Summary:Treating null, boolean and numbers as arrays does not trigger an error Status: Duplicate Type: Bug Package:Variables related Operating System: Linux, Windows PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Thank you for reading my comment with understanding. We have an option to ignore/show E_NOTICE errors of undefined array indexes by setting error_reporting, why can't we have an option for not ignoring this behaviour? That could be easily fixed with no problems to backward compatibility, making it a behavior of E_STRICT or we could add an another E_ option for this. Previous Comments: [2011-06-14 15:51:14] ahar...@php.net This is intended behaviour, per bug #41195. [2011-06-13 19:14:44] cagret at gmail dot com If implementing it is a performance problem (can't think of any other reason why it still hasn't been fixed), then you could at least give us an option, for example a php.ini option "check_types" that would be checking for such error. That would allow us to enable this option on Developer machines during testings and hopefully we would catch and fix all of these errors before uploading the code to the Production machine. ---- [2011-06-11 02:19:47] cagret at gmail dot com Description: This bug is really annoying and generates many headeaches to millions of php developers. It's really hard to detect this bug sometimes, and that is because we have so much faith in PHP and we think that it's not possible that php would allow us to write such a nonsensical code and not throw an error, after all didn't we set the most strict error reporting you allow us to set? This example code should be self explanatory: Please fix it ASAP. Thank you for your time. -- Edit this bug report at http://bugs.php.net/bug.php?id=55032&edit=1
Bug #55032 [Com]: Treating null, boolean and numbers as arrays does not trigger an error
Edit report at http://bugs.php.net/bug.php?id=55032&edit=1 ID: 55032 Comment by: cagret at gmail dot com Reported by:cagret at gmail dot com Summary:Treating null, boolean and numbers as arrays does not trigger an error Status: Open Type: Bug Package:Variables related Operating System: Linux, Windows PHP Version:5.3.6 Block user comment: N Private report: N New Comment: If implementing it is a performance problem (can't think of any other reason why it still hasn't been fixed), then you could at least give us an option, for example a php.ini option "check_types" that would be checking for such error. That would allow us to enable this option on Developer machines during testings and hopefully we would catch and fix all of these errors before uploading the code to the Production machine. Previous Comments: ---- [2011-06-11 02:19:47] cagret at gmail dot com Description: This bug is really annoying and generates many headeaches to millions of php developers. It's really hard to detect this bug sometimes, and that is because we have so much faith in PHP and we think that it's not possible that php would allow us to write such a nonsensical code and not throw an error, after all didn't we set the most strict error reporting you allow us to set? This example code should be self explanatory: Please fix it ASAP. Thank you for your time. -- Edit this bug report at http://bugs.php.net/bug.php?id=55032&edit=1
[PHP-BUG] Bug #55032 [NEW]: Treating null, boolean and numbers as arrays does not trigger an error
From: Operating system: Linux, Windows PHP version: 5.3.6 Package: Variables related Bug Type: Bug Bug description:Treating null, boolean and numbers as arrays does not trigger an error Description: This bug is really annoying and generates many headeaches to millions of php developers. It's really hard to detect this bug sometimes, and that is because we have so much faith in PHP and we think that it's not possible that php would allow us to write such a nonsensical code and not throw an error, after all didn't we set the most strict error reporting you allow us to set? This example code should be self explanatory: Please fix it ASAP. Thank you for your time. -- Edit bug report at http://bugs.php.net/bug.php?id=55032&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=55032&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=55032&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=55032&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=55032&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=55032&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=55032&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=55032&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=55032&r=needscript Try newer version: http://bugs.php.net/fix.php?id=55032&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=55032&r=support Expected behavior: http://bugs.php.net/fix.php?id=55032&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=55032&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=55032&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=55032&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=55032&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=55032&r=dst IIS Stability: http://bugs.php.net/fix.php?id=55032&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=55032&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=55032&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=55032&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=55032&r=mysqlcfg
[PHP-BUG] Bug #53252 [NEW]: Invalid type (boolean) returned by substr() when providing an empty string
From:
Operating system: Linux, Windows
PHP version: 5.3.3
Package: Strings related
Bug Type: Bug
Bug description:Invalid type (boolean) returned by substr() when providing an
empty string
Description:
substr() returns boolean false when providing an empty string as first
argument,
but it should return an empty string "".
Example:
Output:
boolean (false)
There is an *error in php documentation*:
http://pl.php.net/manual/en/function.substr.php
See the example for the third argument "Length":
>> $rest = substr("abcdef", 4, -4); // returns ""
That is not true, $rest contains FALSE and not "".
Cheers,
Cezary Tomczak
--
Edit bug report at http://bugs.php.net/bug.php?id=53252&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53252&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53252&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53252&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53252&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53252&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53252&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53252&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53252&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53252&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53252&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53252&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53252&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53252&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53252&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53252&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53252&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53252&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53252&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53252&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53252&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53252&r=mysqlcfg
#50707 [Bgs]: Sqlite3Result->columnType() always returns SQLITE3_NULL
ID: 50707
User updated by: cagret at gmail dot com
Reported By: cagret at gmail dot com
Status: Bogus
Bug Type: SQLite related
Operating System: Win xp pro
PHP Version: 5.3.1
New Comment:
What do you mean by "no type conversions have occured", "as described
below" > am I missing something? Where in my code am I making any type
conversions?
I don't quite understand, what is this function for, if it always
returns SQLITE3_NULL ?
I was creating a web based browser for sqlite3 database files, in
column headers I want to display column type:
Id (int) | Name (varchar)
That's all, what is the way of doing that?
I've found a solution, but it looks like a way around, using
columnType() would be easier. I am parsing the "CREATE TABLE..." sql
that i fetch by querying sqlite_master table, using a simple regexp.
Here is the function:
function sqlite3_columns($table)
{
global $db;
// $result->columnType(0) - bug, always returns SQLITE3_NULL
$query = sprintf("SELECT * FROM sqlite_master WHERE type='table' and
name='%s'", $table);
$result = $db->query($query);
$row = $result->fetchArray(SQLITE3_ASSOC);
$result->finalize();
$sql = $row['sql'];
preg_match_all('#[\(,]\s*(\w+)\s+(\w+)#', $sql, $pmatch);
$columns = array();
foreach ($pmatch[1] as $k => $colname) {
$columns[] = array('name'=>$colname, 'type'=>$pmatch[2][$k]);
}
return $columns;
}
Previous Comments:
[2010-01-11 02:47:53] il...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The value returned by sqlite3_column_type() is only meaningful if no
type conversions have occurred as described below. After a type
conversion, the value returned by sqlite3_column_type() is undefined.
[2010-01-09 12:48:35] cagret at gmail dot com
Description:
Sqlite3Result->columnType() always returns SQLITE3_NULL.
Table structure:
CREATE TABLE IF NOT EXISTS Test (Id int primary key, Name varchar(50));
Reproduce code:
---
$query = sprintf('SELECT * FROM %s', $table);
$result = $db->query($query);
$columns = array();
$numcols = $result->numColumns();
for ($i = 0; $i < $numcols; $i++) {
$colname = $result->columnName($i);
$coltype = $result->columnType($i);
}
$coltype == 5 (SQLITE3_NULL) for each column.
Expected result:
SQLITE3_INTEGER or SQLITE3_TEXT
Actual result:
--
SQLITE3_NULL
--
Edit this bug report at http://bugs.php.net/?id=50707&edit=1
#50707 [NEW]: Sqlite3Result->columnType() always returns SQLITE3_NULL
From: cagret at gmail dot com
Operating system: Win xp pro
PHP version: 5.3.1
PHP Bug Type: SQLite related
Bug description: Sqlite3Result->columnType() always returns SQLITE3_NULL
Description:
Sqlite3Result->columnType() always returns SQLITE3_NULL.
Table structure:
CREATE TABLE IF NOT EXISTS Test (Id int primary key, Name varchar(50));
Reproduce code:
---
$query = sprintf('SELECT * FROM %s', $table);
$result = $db->query($query);
$columns = array();
$numcols = $result->numColumns();
for ($i = 0; $i < $numcols; $i++) {
$colname = $result->columnName($i);
$coltype = $result->columnType($i);
}
$coltype == 5 (SQLITE3_NULL) for each column.
Expected result:
SQLITE3_INTEGER or SQLITE3_TEXT
Actual result:
--
SQLITE3_NULL
--
Edit bug report at http://bugs.php.net/?id=50707&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50707&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50707&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50707&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50707&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50707&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50707&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50707&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50707&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50707&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50707&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50707&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50707&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50707&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50707&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50707&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50707&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50707&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50707&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50707&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50707&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50707&r=mysqlcfg
#48475 [Opn->Bgs]: register_shutdown_function() does not execute after exit()
ID: 48475 User updated by: cagret at gmail dot com Reported By: cagret at gmail dot com -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: win32 only - Win XP SP3 PHP Version: 5.2.9 New Comment: Sorry, this is not a bug, I've found what was the problem, on Windows I had in php.ini directive auto_prepend_file which included auto_prepend.php and that file registered shutdown function debug_console() which had exit() inside! Previous Comments: [2009-06-16 04:46:12] cagret at gmail dot com I've just tested: Linux + Apache2 + php 5.2.9 as mod: shutdown.txt IS created. (http://testreg.netii.net/phpinfo.php) [2009-06-15 08:41:09] paj...@php.net I'm not sure it is windows specific. What's about Linux+Apache+php5 as mod? [2009-06-15 08:38:37] j...@php.net And as it only happens with windows, it's a bug that needs to be fixed: exit() should exit there too. ---- [2009-06-10 19:36:52] cagret at gmail dot com I have installed php as fcgi under lighttpd on windows, and register_shutdown_function() is called after exit - all versions of php. The same under linux - I have tested many more configurations. It seems that only under Apache on windows, register_shutdown_function() is not executed. If this is expected behavior, than why it acts differently on different setups? Something is wrong. In manual it is said, that after exit() called inside function registered by register_shutdown_function() nothing more will be executed, but here exit() is called outside of registered function. In comments on http://www.php.net/register_shutdown_function there are code examples that show that even after exit() that is not called inside registered shutdown function, the registered function IS executed - people think the other way about the expected behaviour. And if this is expected behavior, it works as expected only on Windows Apache and php5 as php_mod. I've made another test, Win + Apache + php5 as fcgi - and the file shutdown.txt is created after exit(). Summary: I've tested over 10 configurations, Windows, Linux, Apache, Lightpd, php4, php5, php as cgi, php as mod - the only configuration that does not execute register_shutdown_function() after exit (that is called outside of registered function) is: Win + Apache + php5 as mod. I don't think this is expected behavior, because it behaves as expected only on this configuration: Win+Apache+php5_as_mod.Please reconsider re-opening this issue. Configurations summary: Win+Apache+php5 as cgi - shutdown.txt is created Win+Apache+php4 as mod - shutdown.txt is created Win+Lighttpd+php5 as fcgi - shutdown.txt is created Linux+Apache+php4 as mod - shutdown.txt is created Linux+Lighttpd+php5 as fcgi - shutdown.txt is created Win+Apache+php5 as mod - shutdown.txt IS NOT created. [2009-06-10 12:59:18] j...@php.net Expected behaviour. exit() is supposed to exit immediately. Nothing is supposed to be run after you call exit. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/48475 -- Edit this bug report at http://bugs.php.net/?id=48475&edit=1
#48475 [Fbk->Opn]: register_shutdown_function() does not execute after exit()
ID: 48475 User updated by: cagret at gmail dot com Reported By: cagret at gmail dot com -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: win32 only - Win XP SP3 PHP Version: 5.2.9 New Comment: I've just tested: Linux + Apache2 + php 5.2.9 as mod: shutdown.txt IS created. (http://testreg.netii.net/phpinfo.php) Previous Comments: [2009-06-15 08:41:09] paj...@php.net I'm not sure it is windows specific. What's about Linux+Apache+php5 as mod? [2009-06-15 08:38:37] j...@php.net And as it only happens with windows, it's a bug that needs to be fixed: exit() should exit there too. [2009-06-10 19:36:52] cagret at gmail dot com I have installed php as fcgi under lighttpd on windows, and register_shutdown_function() is called after exit - all versions of php. The same under linux - I have tested many more configurations. It seems that only under Apache on windows, register_shutdown_function() is not executed. If this is expected behavior, than why it acts differently on different setups? Something is wrong. In manual it is said, that after exit() called inside function registered by register_shutdown_function() nothing more will be executed, but here exit() is called outside of registered function. In comments on http://www.php.net/register_shutdown_function there are code examples that show that even after exit() that is not called inside registered shutdown function, the registered function IS executed - people think the other way about the expected behaviour. And if this is expected behavior, it works as expected only on Windows Apache and php5 as php_mod. I've made another test, Win + Apache + php5 as fcgi - and the file shutdown.txt is created after exit(). Summary: I've tested over 10 configurations, Windows, Linux, Apache, Lightpd, php4, php5, php as cgi, php as mod - the only configuration that does not execute register_shutdown_function() after exit (that is called outside of registered function) is: Win + Apache + php5 as mod. I don't think this is expected behavior, because it behaves as expected only on this configuration: Win+Apache+php5_as_mod.Please reconsider re-opening this issue. Configurations summary: Win+Apache+php5 as cgi - shutdown.txt is created Win+Apache+php4 as mod - shutdown.txt is created Win+Lighttpd+php5 as fcgi - shutdown.txt is created Linux+Apache+php4 as mod - shutdown.txt is created Linux+Lighttpd+php5 as fcgi - shutdown.txt is created Win+Apache+php5 as mod - shutdown.txt IS NOT created. [2009-06-10 12:59:18] j...@php.net Expected behaviour. exit() is supposed to exit immediately. Nothing is supposed to be run after you call exit. -------- [2009-06-05 02:41:52] cagret at gmail dot com Description: Function registered with register_shutdown_function() is not executed after call to exit() on windows with latest php (php5 - failed, php4 - ok). On linux it works as expected (both php4 & php5 - ok). I have tested many configurations, here is the summary: * Win XP Sp3, Apache/2.2.11 php_mod, php versions: 5.2.9-2, 5.2.6, 5.2.8, 5.2.10RC1, 5.3.0RC2 (all versions FAILED) * Win XP Sp3, Apache/1.3.34, php_mod, php 4.4.3-dev (OK) * Linux, Lighttpd, cgi-fcgi, php 5.2.6 (OK) * Linux, Apache/2.0.52 (CentOS), php_mod, php 4.3.9 (OK) Reproduce code: --- -- Edit this bug report at http://bugs.php.net/?id=48475&edit=1
#48552 [NEW]: register_shutdown_function random behavior on different platforms after exit
From: cagret at gmail dot com Operating system: Win/Linux/Apache/Lighttpd PHP version: 5.2.9 PHP Bug Type: Unknown/Other Function Bug description: register_shutdown_function random behavior on different platforms after exit Description: Function registered with register_shutdown_function() sometimes is executed / sometimes it is not, after you exit (outside of registered function) - depends on php configuration. Win+Apache+php5 as mod - shutdown.txt IS NOT created. Win+Apache+php5 as cgi - shutdown.txt IS created Win+Apache+php4 as mod - shutdown.txt IS created Win+Lighttpd+php5 as fcgi - shutdown.txt IS created Linux+Apache+php4 as mod - shutdown.txt IS created Linux+Lighttpd+php5 as fcgi - shutdown.txt IS created I've thought this is a bug on Win+Apache+php5asmod, and reported it, but j...@php.net (http://bugs.php.net/bug.php?id=48475) says it is an expected behavior: "Expected behaviour. exit() is supposed to exit immediately. Nothing is supposed to be run after you call exit." If this is an expected behavior, then seems like there is a bug on other php configurations. Reproduce code: --- Expected result: shutdown.txt should not be created. Actual result: -- shutdown.txt is created -- Edit bug report at http://bugs.php.net/?id=48552&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48552&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48552&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48552&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48552&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48552&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48552&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48552&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48552&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48552&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48552&r=support Expected behavior: http://bugs.php.net/fix.php?id=48552&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48552&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48552&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48552&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48552&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48552&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48552&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48552&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48552&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48552&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48552&r=mysqlcfg
#48475 [Bgs]: register_shutdown_function() does not execute after exit()
ID: 48475 User updated by: cagret at gmail dot com Reported By: cagret at gmail dot com Status: Bogus -Bug Type: *General Issues +Bug Type: Apache2 related Operating System: Win XP SP3 PHP Version: 5.2.9 New Comment: I have installed php as fcgi under lighttpd on windows, and register_shutdown_function() is called after exit - all versions of php. The same under linux - I have tested many more configurations. It seems that only under Apache on windows, register_shutdown_function() is not executed. If this is expected behavior, than why it acts differently on different setups? Something is wrong. In manual it is said, that after exit() called inside function registered by register_shutdown_function() nothing more will be executed, but here exit() is called outside of registered function. In comments on http://www.php.net/register_shutdown_function there are code examples that show that even after exit() that is not called inside registered shutdown function, the registered function IS executed - people think the other way about the expected behaviour. And if this is expected behavior, it works as expected only on Windows Apache and php5 as php_mod. I've made another test, Win + Apache + php5 as fcgi - and the file shutdown.txt is created after exit(). Summary: I've tested over 10 configurations, Windows, Linux, Apache, Lightpd, php4, php5, php as cgi, php as mod - the only configuration that does not execute register_shutdown_function() after exit (that is called outside of registered function) is: Win + Apache + php5 as mod. I don't think this is expected behavior, because it behaves as expected only on this configuration: Win+Apache+php5_as_mod.Please reconsider re-opening this issue. Configurations summary: Win+Apache+php5 as cgi - shutdown.txt is created Win+Apache+php4 as mod - shutdown.txt is created Win+Lighttpd+php5 as fcgi - shutdown.txt is created Linux+Apache+php4 as mod - shutdown.txt is created Linux+Lighttpd+php5 as fcgi - shutdown.txt is created Win+Apache+php5 as mod - shutdown.txt IS NOT created. Previous Comments: [2009-06-10 12:59:18] j...@php.net Expected behaviour. exit() is supposed to exit immediately. Nothing is supposed to be run after you call exit. [2009-06-05 02:41:52] cagret at gmail dot com Description: Function registered with register_shutdown_function() is not executed after call to exit() on windows with latest php (php5 - failed, php4 - ok). On linux it works as expected (both php4 & php5 - ok). I have tested many configurations, here is the summary: * Win XP Sp3, Apache/2.2.11 php_mod, php versions: 5.2.9-2, 5.2.6, 5.2.8, 5.2.10RC1, 5.3.0RC2 (all versions FAILED) * Win XP Sp3, Apache/1.3.34, php_mod, php 4.4.3-dev (OK) * Linux, Lighttpd, cgi-fcgi, php 5.2.6 (OK) * Linux, Apache/2.0.52 (CentOS), php_mod, php 4.3.9 (OK) Reproduce code: --- -- Edit this bug report at http://bugs.php.net/?id=48475&edit=1
#48475 [NEW]: register_shutdown_function() does not execute after exit()
From: cagret at gmail dot com Operating system: Win XP SP3 PHP version: 5.2.9 PHP Bug Type: Unknown/Other Function Bug description: register_shutdown_function() does not execute after exit() Description: Function registered with register_shutdown_function() is not executed after call to exit() on windows with latest php (php5 - failed, php4 - ok). On linux it works as expected (both php4 & php5 - ok). I have tested many configurations, here is the summary: * Win XP Sp3, Apache/2.2.11 php_mod, php versions: 5.2.9-2, 5.2.6, 5.2.8, 5.2.10RC1, 5.3.0RC2 (all versions FAILED) * Win XP Sp3, Apache/1.3.34, php_mod, php 4.4.3-dev (OK) * Linux, Lighttpd, cgi-fcgi, php 5.2.6 (OK) * Linux, Apache/2.0.52 (CentOS), php_mod, php 4.3.9 (OK) Reproduce code: --- -- Edit bug report at http://bugs.php.net/?id=48475&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48475&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48475&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48475&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48475&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48475&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48475&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48475&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48475&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48475&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48475&r=support Expected behavior: http://bugs.php.net/fix.php?id=48475&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48475&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48475&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48475&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48475&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48475&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48475&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48475&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48475&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48475&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48475&r=mysqlcfg
