Bug #65499 [Csd]: json_decode reports invalid literal as valid JSON
Edit report at https://bugs.php.net/bug.php?id=65499edit=1 ID: 65499 User updated by:m dot kurzyna at crystalpoint dot pl Reported by:m dot kurzyna at crystalpoint dot pl Summary:json_decode reports invalid literal as valid JSON Status: Closed Type: Bug Package:JSON related Operating System: Linux PHP Version:5.5.2 Block user comment: N Private report: N New Comment: Just to follow up - it has been fixed upstream (both in pecl-json-c and main json-c). Hopefully next distro packages will reflect this changes. Thanks all. Previous Comments: [2013-08-23 07:10:08] m dot kurzyna at crystalpoint dot pl Thanks - I've reported the issue accordingly: https://github.com/remicollet/pecl-json-c/issues/5 [2013-08-23 05:39:05] r...@php.net As Fedora, Ubuntu and some other Linux distributions have switch to JSONC extension, you can report this strictness change in https://github.com/remicollet/pecl-json-c/issues?state=open [2013-08-22 15:16:32] m dot kurzyna at crystalpoint dot pl I'm at Ubuntu. I've built current master (from git) and also didn't reproduce this behaviour so just as you suggest - it seems to be packagers problem. I will report to Ubuntu maintainers. [2013-08-22 11:34:15] yohg...@php.net It seems my fedora 19 x86_64 does this, while my PHP-5.5 branch don't on the same machine. It seems packager's issue. $ php ?php var_dump( json_decode(9af5), json_last_error() ); int(9) int(0) [yohgaki@dev PHP-5.5]$ ./php-bin ?php var_dump( json_decode(9af5), json_last_error() ); NULL int(4) [2013-08-22 11:24:39] r...@php.net What is the return of php -r 'echo phpversion(json);' 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 https://bugs.php.net/bug.php?id=65499 -- Edit this bug report at https://bugs.php.net/bug.php?id=65499edit=1
[PHP-BUG] Bug #65499 [NEW]: json_decode reports invalid literal as valid JSON
From: m dot kurzyna at crystalpoint dot pl Operating system: Linux PHP version: 5.5.2 Package: JSON related Bug Type: Bug Bug description:json_decode reports invalid literal as valid JSON Description: There is a regression in json_decode starting with PHP5.5 (5.4.x works as expected). json_decode() now treats literals staring with an integer as valid JSON consisting only of the first character. Test script: --- ?php var_dump( json_decode(9af5), json_last_error() ); Expected result: NULL int(4) Actual result: -- int(9) int(0) -- Edit bug report at https://bugs.php.net/bug.php?id=65499edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65499r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65499r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65499r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65499r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65499r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65499r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65499r=needscript Try newer version: https://bugs.php.net/fix.php?id=65499r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65499r=support Expected behavior: https://bugs.php.net/fix.php?id=65499r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65499r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65499r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65499r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65499r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65499r=dst IIS Stability: https://bugs.php.net/fix.php?id=65499r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65499r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65499r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65499r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65499r=mysqlcfg
Bug #65499 [Opn]: json_decode reports invalid literal as valid JSON
Edit report at https://bugs.php.net/bug.php?id=65499edit=1 ID: 65499 User updated by:m dot kurzyna at crystalpoint dot pl Reported by:m dot kurzyna at crystalpoint dot pl Summary:json_decode reports invalid literal as valid JSON Status: Open Type: Bug Package:JSON related Operating System: Linux PHP Version:5.5.2 Block user comment: N Private report: N New Comment: To be more precise - introduced regression casts the string to integer so technically it takes all first digits just like (int)123abc would do. Previous Comments: [2013-08-22 08:00:25] m dot kurzyna at crystalpoint dot pl Description: There is a regression in json_decode starting with PHP5.5 (5.4.x works as expected). json_decode() now treats literals staring with an integer as valid JSON consisting only of the first character. Test script: --- ?php var_dump( json_decode(9af5), json_last_error() ); Expected result: NULL int(4) Actual result: -- int(9) int(0) -- Edit this bug report at https://bugs.php.net/bug.php?id=65499edit=1
Bug #65499 [Fbk-Csd]: json_decode reports invalid literal as valid JSON
Edit report at https://bugs.php.net/bug.php?id=65499edit=1 ID: 65499 User updated by:m dot kurzyna at crystalpoint dot pl Reported by:m dot kurzyna at crystalpoint dot pl Summary:json_decode reports invalid literal as valid JSON -Status: Feedback +Status: Closed Type: Bug Package:JSON related Operating System: Linux PHP Version:5.5.2 Block user comment: N Private report: N New Comment: I'm at Ubuntu. I've built current master (from git) and also didn't reproduce this behaviour so just as you suggest - it seems to be packagers problem. I will report to Ubuntu maintainers. Previous Comments: [2013-08-22 11:34:15] yohg...@php.net It seems my fedora 19 x86_64 does this, while my PHP-5.5 branch don't on the same machine. It seems packager's issue. $ php ?php var_dump( json_decode(9af5), json_last_error() ); int(9) int(0) [yohgaki@dev PHP-5.5]$ ./php-bin ?php var_dump( json_decode(9af5), json_last_error() ); NULL int(4) [2013-08-22 11:24:39] r...@php.net What is the return of php -r 'echo phpversion(json);' [2013-08-22 11:22:19] m...@php.net Cannot reproduce. Do you use Debian/Ubuntu/Fedora? Report there. [2013-08-22 08:15:54] m dot kurzyna at crystalpoint dot pl To be more precise - introduced regression casts the string to integer so technically it takes all first digits just like (int)123abc would do. [2013-08-22 08:00:25] m dot kurzyna at crystalpoint dot pl Description: There is a regression in json_decode starting with PHP5.5 (5.4.x works as expected). json_decode() now treats literals staring with an integer as valid JSON consisting only of the first character. Test script: --- ?php var_dump( json_decode(9af5), json_last_error() ); Expected result: NULL int(4) Actual result: -- int(9) int(0) -- Edit this bug report at https://bugs.php.net/bug.php?id=65499edit=1
#50458 [NEW]: PDO::FETCH_FUNC fails with Closures
From: m dot kurzyna at crystalpoint dot pl
Operating system: Linux
PHP version: 5.3.1
PHP Bug Type: PDO related
Bug description: PDO::FETCH_FUNC fails with Closures
Description:
PDOStatement::fetchAll(PDO::FETCH_FUNC,function() {}) fails not being able
to recognize Closure as valid callback.
Reproduce code:
---
?php
$db = new PDO('sqlite::memory:');
$db-exec('CREATE TABLE `a` ( `id` INTEGER )');
$st = $db-query('SELECT * FROM `a`');
$st-fetchAll(PDO::FETCH_FUNC,function() {});
?
Expected result:
No error
Actual result:
--
Warning: PDOStatement::fetchAll() [pdostatement.fetchall]:
SQLSTATE[HY000]: General error: user-supplied function must be a valid
callback in ... on line 6
--
Edit bug report at http://bugs.php.net/?id=50458edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50458r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50458r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50458r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50458r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50458r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50458r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50458r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50458r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50458r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50458r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50458r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50458r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50458r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50458r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50458r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50458r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50458r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50458r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50458r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50458r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50458r=mysqlcfg
#49632 [NEW]: xmlrpc_decode result crushes on value assignment
From: m dot kurzyna at crystalpoint dot pl
Operating system: Linux x86_64
PHP version: 5.3.0
PHP Bug Type: XMLRPC-EPI related
Bug description: xmlrpc_decode result crushes on value assignment
Description:
On decoding value with xmlrpc_decode() it will hang/crash PHP process when
trying to assign result value.
This will work fine:
xmlrpc_decode('...','utf-8');
While this:
$r = xmlrpc_decode('...','utf-8');
Will hang/crash.
This only happens on x86_64 systems - 32bit works fine.
Relevant part of the backtrace seems to be:
#24 0x7fffeb297271 in XML_ParseBuffer () from
/usr/lib64/libexpat.so.0
#25 0x7fffeb4c329a in xml_elem_parse_buf () from
/usr/lib64/libxmlrpc.so.0
#26 0x7fffeb4c74e9 in XMLRPC_REQUEST_FromXML () from
/usr/lib64/libxmlrpc.so.0
#27 0x7fffeb6d3523 in decode_request_worker (xml_in=0x7637ee60
\2, xml_in_len=128, encoding_in=value optimized out,
method_name_out=0x) at
/usr/src/debug/php-5.3.0/ext/xmlrpc/xmlrpc-epi-php.c:764
#28 0x7fffeb6d3630 in zif_xmlrpc_decode (ht=value optimized out,
return_value=0x86e5e0, return_value_ptr=value optimized out,
this_ptr=value optimized out, return_value_used=1, tsrm_ls=0x606ce0)
at /usr/src/debug/php-5.3.0/ext/xmlrpc/xmlrpc-epi-php.c:821
I will provide full trace if needed.
Reproduce code:
---
?php
$v = xmlrpc_decode(
'?xml version=1.0?
methodResponse
params
param
value
string1/string
/value
/param
/params
/methodResponse','utf-8');
echo OK\n;
?
Expected result:
OK
Actual result:
--
*** glibc detected *** /usr/bin/php: free(): invalid next size (fast):
0x008a7540 ***
--
Edit bug report at http://bugs.php.net/?id=49632edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49632r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49632r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49632r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49632r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49632r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49632r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49632r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49632r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49632r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49632r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49632r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49632r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49632r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49632r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49632r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49632r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49632r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49632r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49632r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49632r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49632r=mysqlcfg
#49632 [Fbk-Opn]: xmlrpc_decode result crashes on value assignment
ID: 49632
User updated by: m dot kurzyna at crystalpoint dot pl
Reported By: m dot kurzyna at crystalpoint dot pl
-Status: Feedback
+Status: Open
Bug Type: XMLRPC-EPI related
Operating System: Linux x86_64
PHP Version: 5.3.0
New Comment:
Unfortunatly i can reproduce it every time even on bare setup:
[r...@apache-php53 bugs]# php -m
[PHP Modules]
Core
date
ereg
libxml
mysqlnd
pcre
Reflection
session
SPL
standard
xmlrpc
[Zend Modules]
[r...@apache-php53 bugs]# php xmlrpc_decode.php
*** glibc detected *** php: free(): invalid next size (fast):
0x0079fbd0 ***
And then backtrace follows, see: http://pastebin.com/f5ed2df2d for full
output.
Previous Comments:
[2009-09-22 20:32:11] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
I can not reproduce this. Also make sure you're not loading any zend
extensions..
[2009-09-22 20:23:20] m dot kurzyna at crystalpoint dot pl
Description:
On decoding value with xmlrpc_decode() it will hang/crash PHP process
when trying to assign result value.
This will work fine:
xmlrpc_decode('...','utf-8');
While this:
$r = xmlrpc_decode('...','utf-8');
Will hang/crash.
This only happens on x86_64 systems - 32bit works fine.
Relevant part of the backtrace seems to be:
#24 0x7fffeb297271 in XML_ParseBuffer () from
/usr/lib64/libexpat.so.0
#25 0x7fffeb4c329a in xml_elem_parse_buf () from
/usr/lib64/libxmlrpc.so.0
#26 0x7fffeb4c74e9 in XMLRPC_REQUEST_FromXML () from
/usr/lib64/libxmlrpc.so.0
#27 0x7fffeb6d3523 in decode_request_worker (xml_in=0x7637ee60
\2, xml_in_len=128, encoding_in=value optimized out,
method_name_out=0x) at
/usr/src/debug/php-5.3.0/ext/xmlrpc/xmlrpc-epi-php.c:764
#28 0x7fffeb6d3630 in zif_xmlrpc_decode (ht=value optimized out,
return_value=0x86e5e0, return_value_ptr=value optimized out,
this_ptr=value optimized out, return_value_used=1, tsrm_ls=0x606ce0)
at /usr/src/debug/php-5.3.0/ext/xmlrpc/xmlrpc-epi-php.c:821
I will provide full trace if needed.
Reproduce code:
---
?php
$v = xmlrpc_decode(
'?xml version=1.0?
methodResponse
params
param
value
string1/string
/value
/param
/params
/methodResponse','utf-8');
echo OK\n;
?
Expected result:
OK
Actual result:
--
*** glibc detected *** /usr/bin/php: free(): invalid next size (fast):
0x008a7540 ***
--
Edit this bug report at http://bugs.php.net/?id=49632edit=1
#49632 [Opn-Csd]: xmlrpc_decode result crashes on value assignment
ID: 49632
User updated by: m dot kurzyna at crystalpoint dot pl
Reported By: m dot kurzyna at crystalpoint dot pl
-Status: Open
+Status: Closed
Bug Type: XMLRPC-EPI related
Operating System: Linux x86_64
PHP Version: 5.3.0
New Comment:
I've just built current snap (2009.09.22 20:30) and it seems to work
fine so it would seem that it's fixed in SVN.
Thanks.
Previous Comments:
[2009-09-22 20:50:46] m dot kurzyna at crystalpoint dot pl
Unfortunatly i can reproduce it every time even on bare setup:
[r...@apache-php53 bugs]# php -m
[PHP Modules]
Core
date
ereg
libxml
mysqlnd
pcre
Reflection
session
SPL
standard
xmlrpc
[Zend Modules]
[r...@apache-php53 bugs]# php xmlrpc_decode.php
*** glibc detected *** php: free(): invalid next size (fast):
0x0079fbd0 ***
And then backtrace follows, see: http://pastebin.com/f5ed2df2d for full
output.
[2009-09-22 20:32:11] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
I can not reproduce this. Also make sure you're not loading any zend
extensions..
[2009-09-22 20:23:20] m dot kurzyna at crystalpoint dot pl
Description:
On decoding value with xmlrpc_decode() it will hang/crash PHP process
when trying to assign result value.
This will work fine:
xmlrpc_decode('...','utf-8');
While this:
$r = xmlrpc_decode('...','utf-8');
Will hang/crash.
This only happens on x86_64 systems - 32bit works fine.
Relevant part of the backtrace seems to be:
#24 0x7fffeb297271 in XML_ParseBuffer () from
/usr/lib64/libexpat.so.0
#25 0x7fffeb4c329a in xml_elem_parse_buf () from
/usr/lib64/libxmlrpc.so.0
#26 0x7fffeb4c74e9 in XMLRPC_REQUEST_FromXML () from
/usr/lib64/libxmlrpc.so.0
#27 0x7fffeb6d3523 in decode_request_worker (xml_in=0x7637ee60
\2, xml_in_len=128, encoding_in=value optimized out,
method_name_out=0x) at
/usr/src/debug/php-5.3.0/ext/xmlrpc/xmlrpc-epi-php.c:764
#28 0x7fffeb6d3630 in zif_xmlrpc_decode (ht=value optimized out,
return_value=0x86e5e0, return_value_ptr=value optimized out,
this_ptr=value optimized out, return_value_used=1, tsrm_ls=0x606ce0)
at /usr/src/debug/php-5.3.0/ext/xmlrpc/xmlrpc-epi-php.c:821
I will provide full trace if needed.
Reproduce code:
---
?php
$v = xmlrpc_decode(
'?xml version=1.0?
methodResponse
params
param
value
string1/string
/value
/param
/params
/methodResponse','utf-8');
echo OK\n;
?
Expected result:
OK
Actual result:
--
*** glibc detected *** /usr/bin/php: free(): invalid next size (fast):
0x008a7540 ***
--
Edit this bug report at http://bugs.php.net/?id=49632edit=1
#49510 [Asn]: boolean validation fails with FILTER_NULL_ON_FAILURE
ID: 49510
User updated by: m dot kurzyna at crystalpoint dot pl
Reported By: m dot kurzyna at crystalpoint dot pl
Status: Assigned
Bug Type: Filter related
Operating System: Linux
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
Actually it is broken even more then i initially reported because it
also returns NULL for empty string:
filter_var('',FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE))
// got NULL, expected false
The problem is in ext/filter/logical_filters.c(233) - the check is done
by using string representation of zval being checked. For false value
it's an empty string and the switch from line 244 doesn't cover this
case (hence same result for false and empty string).
Something along the lines of following patch should fix the problem:
--- logical_filters.c 2009-06-10 21:01:17.0 +0200
+++ logical_filters.fixed.c 2009-09-10 10:48:59.953675880 +0200
@@ -242,6 +242,10 @@
* returns false for 0, false, off, no, and
* null otherwise. */
switch (len) {
+ case 0:
+ ret = 0;
+ break;
+
case 1:
if (*str == '1') {
ret = 1;
On the side note: i was always wondering why (string)false == '' and
not '0'?
Previous Comments:
[2009-09-09 23:00:32] paj...@php.net
This case sounds wrong:
filter_var(false,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got NULL, expected false
I have to check back the code, but this case does not make sense to me.
[2009-09-09 22:30:34] m dot kurzyna at crystalpoint dot pl
If this is, as you say, intended behaviour then sorry, but it's broken
by design. Although because of BC it'll never get fixed unfortunately so
i'll just vent my frustration.
In current state you have no way to use filters to *validate* boolean
input (note that this is filter_validate_boolean not
filter_sanitize_boolean - there is no such).
As a sanitizer it's also broken though because real boolean values
can't be used (or distinguished from error values when
FILTER_NULL_ON_FAILURE is given) so you'd have to first check whether
value is boolean and if not try to sanitize it to boolean using
validating filter. It even sound broken.
Also it's internally inconsistent. It works as expected for plain
filtering:
var_dump(
filter_var(true,FILTER_VALIDATE_BOOLEAN), // true
filter_var(true,FILTER_VALIDATE_BOOLEAN), // true
filter_var(1,FILTER_VALIDATE_BOOLEAN), // true
filter_var(1,FILTER_VALIDATE_BOOLEAN),// true
filter_var(on,FILTER_VALIDATE_BOOLEAN), // true
filter_var(yes,FILTER_VALIDATE_BOOLEAN) // true
);
var_dump(
filter_var(false,FILTER_VALIDATE_BOOLEAN), // false
filter_var(false,FILTER_VALIDATE_BOOLEAN),// false
filter_var(0,FILTER_VALIDATE_BOOLEAN), // false
filter_var(0,FILTER_VALIDATE_BOOLEAN),// false
filter_var(off,FILTER_VALIDATE_BOOLEAN), // false
filter_var(no,FILTER_VALIDATE_BOOLEAN)// false
);
var_dump(
filter_var(7,FILTER_VALIDATE_BOOLEAN), // false
filter_var(garbage,FILTER_VALIDATE_BOOLEAN) // false
);
But fails to keep consistency when i try to distinguish whether value
is boolean or not witch should be the sole role of *VALIDATE* filter:
var_dump(
filter_var(true,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got true, expected true
filter_var(true,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got true, expected true
filter_var(1,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got true, expected true
filter_var(1,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got true, expected true
filter_var(on,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got true, expected true
filter_var(yes,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE))
// got true, expected true
);
var_dump(
filter_var(false,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got NULL, expected false
filter_var(false,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got false, expected false
filter_var(0,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got false, expected false
filter_var(0,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got false, expected false
filter_var(off,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got
#49510 [Asn]: boolean validation fails with FILTER_NULL_ON_FAILURE
ID: 49510
User updated by: m dot kurzyna at crystalpoint dot pl
Reported By: m dot kurzyna at crystalpoint dot pl
Status: Assigned
Bug Type: Filter related
Operating System: Linux
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
Personally i think it's just fine (empty string ain't false - if
anything it's null) but in PHP world it is (both on PHP and C levels):
(string)false = ''
(boolean)'' == false
Z_STRLEN_P(value) = 0
Oh, and there is this little documentation thingy you like to cite from
time to time:
If FILTER_NULL_ON_FAILURE is set, FALSE is returned only for 0,
false, off, no, and , and NULL is returned for all non-boolean
values.
where empty string is explicitly stated as being false.
Previous Comments:
[2009-09-10 08:57:29] sjo...@php.net
Why do you think it is wrong that it returns null for an empty string?
[2009-09-10 08:53:11] m dot kurzyna at crystalpoint dot pl
Actually it is broken even more then i initially reported because it
also returns NULL for empty string:
filter_var('',FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE))
// got NULL, expected false
The problem is in ext/filter/logical_filters.c(233) - the check is done
by using string representation of zval being checked. For false value
it's an empty string and the switch from line 244 doesn't cover this
case (hence same result for false and empty string).
Something along the lines of following patch should fix the problem:
--- logical_filters.c 2009-06-10 21:01:17.0 +0200
+++ logical_filters.fixed.c 2009-09-10 10:48:59.953675880 +0200
@@ -242,6 +242,10 @@
* returns false for 0, false, off, no, and
* null otherwise. */
switch (len) {
+ case 0:
+ ret = 0;
+ break;
+
case 1:
if (*str == '1') {
ret = 1;
On the side note: i was always wondering why (string)false == '' and
not '0'?
[2009-09-09 23:00:32] paj...@php.net
This case sounds wrong:
filter_var(false,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got NULL, expected false
I have to check back the code, but this case does not make sense to me.
[2009-09-09 22:30:34] m dot kurzyna at crystalpoint dot pl
If this is, as you say, intended behaviour then sorry, but it's broken
by design. Although because of BC it'll never get fixed unfortunately so
i'll just vent my frustration.
In current state you have no way to use filters to *validate* boolean
input (note that this is filter_validate_boolean not
filter_sanitize_boolean - there is no such).
As a sanitizer it's also broken though because real boolean values
can't be used (or distinguished from error values when
FILTER_NULL_ON_FAILURE is given) so you'd have to first check whether
value is boolean and if not try to sanitize it to boolean using
validating filter. It even sound broken.
Also it's internally inconsistent. It works as expected for plain
filtering:
var_dump(
filter_var(true,FILTER_VALIDATE_BOOLEAN), // true
filter_var(true,FILTER_VALIDATE_BOOLEAN), // true
filter_var(1,FILTER_VALIDATE_BOOLEAN), // true
filter_var(1,FILTER_VALIDATE_BOOLEAN),// true
filter_var(on,FILTER_VALIDATE_BOOLEAN), // true
filter_var(yes,FILTER_VALIDATE_BOOLEAN) // true
);
var_dump(
filter_var(false,FILTER_VALIDATE_BOOLEAN), // false
filter_var(false,FILTER_VALIDATE_BOOLEAN),// false
filter_var(0,FILTER_VALIDATE_BOOLEAN), // false
filter_var(0,FILTER_VALIDATE_BOOLEAN),// false
filter_var(off,FILTER_VALIDATE_BOOLEAN), // false
filter_var(no,FILTER_VALIDATE_BOOLEAN)// false
);
var_dump(
filter_var(7,FILTER_VALIDATE_BOOLEAN), // false
filter_var(garbage,FILTER_VALIDATE_BOOLEAN) // false
);
But fails to keep consistency when i try to distinguish whether value
is boolean or not witch should be the sole role of *VALIDATE* filter:
var_dump(
filter_var(true,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got true, expected true
filter_var(true,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got true, expected true
filter_var(1,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got true, expected true
filter_var(1,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got true, expected true
filter_var(on,FILTER_VALIDATE_BOOLEAN
#49510 [Asn]: boolean validation fails with FILTER_NULL_ON_FAILURE
ID: 49510
User updated by: m dot kurzyna at crystalpoint dot pl
Reported By: m dot kurzyna at crystalpoint dot pl
Status: Assigned
Bug Type: Filter related
Operating System: Linux
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
As much as i'd like to have empty string be invalid false cast i have
to disagree with you for consistency reasons.
If (boolean)'' == false then filter_var('','boolean') should also
return false. Both in general and in case of FILTER_NULL_ON_FAILURE
(just like the documentation states).
Also, because i can't stress it enough, this is a VALIDATOR not a
SANITIZER so using it as a strict caster is secondary to it's validation
purpose and as such it currently fails both on implied and explicit
behavior.
The ideal solution would be to have FILTER_VALIDATE_BOOLEAN roughly
equal to current behavior with FILTER_NULL_ON_FAILURE and a *seperate*
FILTER_SANITIZE_BOOLEAN similar to current behavior w/o the null failure
flag. This however probably is impossible due to BC.
Previous Comments:
[2009-09-10 11:09:43] sjo...@php.net
I agree that filter_var() should return null for the empty string. I
think that this usage of filter_var() is meant to convert string
representations of booleans to boolean values. That is, true, on,
1, false, off and 0 should be converted, other strings should
return null.
[2009-09-10 09:05:53] m dot kurzyna at crystalpoint dot pl
Personally i think it's just fine (empty string ain't false - if
anything it's null) but in PHP world it is (both on PHP and C levels):
(string)false = ''
(boolean)'' == false
Z_STRLEN_P(value) = 0
Oh, and there is this little documentation thingy you like to cite from
time to time:
If FILTER_NULL_ON_FAILURE is set, FALSE is returned only for 0,
false, off, no, and , and NULL is returned for all non-boolean
values.
where empty string is explicitly stated as being false.
[2009-09-10 08:57:29] sjo...@php.net
Why do you think it is wrong that it returns null for an empty string?
[2009-09-10 08:53:11] m dot kurzyna at crystalpoint dot pl
Actually it is broken even more then i initially reported because it
also returns NULL for empty string:
filter_var('',FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE))
// got NULL, expected false
The problem is in ext/filter/logical_filters.c(233) - the check is done
by using string representation of zval being checked. For false value
it's an empty string and the switch from line 244 doesn't cover this
case (hence same result for false and empty string).
Something along the lines of following patch should fix the problem:
--- logical_filters.c 2009-06-10 21:01:17.0 +0200
+++ logical_filters.fixed.c 2009-09-10 10:48:59.953675880 +0200
@@ -242,6 +242,10 @@
* returns false for 0, false, off, no, and
* null otherwise. */
switch (len) {
+ case 0:
+ ret = 0;
+ break;
+
case 1:
if (*str == '1') {
ret = 1;
On the side note: i was always wondering why (string)false == '' and
not '0'?
[2009-09-09 23:00:32] paj...@php.net
This case sounds wrong:
filter_var(false,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got NULL, expected false
I have to check back the code, but this case does not make sense to me.
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/49510
--
Edit this bug report at http://bugs.php.net/?id=49510edit=1
#49510 [NEW]: boolean validation fails with FILTER_NULL_ON_FAILURE
From: m dot kurzyna at crystalpoint dot pl Operating system: Linux PHP version: 5.3.0 PHP Bug Type: Filter related Bug description: boolean validation fails with FILTER_NULL_ON_FAILURE Description: filter_var() when validating (boolean)false with FILTER_NULL_ON_FAILURE returns null instead of false. Reproduce code: --- var_dump( filter_var(false, FILTER_VALIDATE_BOOLEAN, array(flags = FILTER_NULL_ON_FAILURE) ) ); Expected result: false Actual result: -- null -- Edit bug report at http://bugs.php.net/?id=49510edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49510r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49510r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49510r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49510r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49510r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49510r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49510r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49510r=needscript Try newer version: http://bugs.php.net/fix.php?id=49510r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49510r=support Expected behavior: http://bugs.php.net/fix.php?id=49510r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49510r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49510r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49510r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49510r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49510r=dst IIS Stability: http://bugs.php.net/fix.php?id=49510r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49510r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49510r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49510r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49510r=mysqlcfg
#49510 [Bgs]: boolean validation fails with FILTER_NULL_ON_FAILURE
ID: 49510
User updated by: m dot kurzyna at crystalpoint dot pl
Reported By: m dot kurzyna at crystalpoint dot pl
Status: Bogus
Bug Type: Filter related
Operating System: Linux
PHP Version: 5.3.0
New Comment:
If this is, as you say, intended behaviour then sorry, but it's broken
by design. Although because of BC it'll never get fixed unfortunately so
i'll just vent my frustration.
In current state you have no way to use filters to *validate* boolean
input (note that this is filter_validate_boolean not
filter_sanitize_boolean - there is no such).
As a sanitizer it's also broken though because real boolean values
can't be used (or distinguished from error values when
FILTER_NULL_ON_FAILURE is given) so you'd have to first check whether
value is boolean and if not try to sanitize it to boolean using
validating filter. It even sound broken.
Also it's internally inconsistent. It works as expected for plain
filtering:
var_dump(
filter_var(true,FILTER_VALIDATE_BOOLEAN), // true
filter_var(true,FILTER_VALIDATE_BOOLEAN), // true
filter_var(1,FILTER_VALIDATE_BOOLEAN), // true
filter_var(1,FILTER_VALIDATE_BOOLEAN),// true
filter_var(on,FILTER_VALIDATE_BOOLEAN), // true
filter_var(yes,FILTER_VALIDATE_BOOLEAN) // true
);
var_dump(
filter_var(false,FILTER_VALIDATE_BOOLEAN), // false
filter_var(false,FILTER_VALIDATE_BOOLEAN),// false
filter_var(0,FILTER_VALIDATE_BOOLEAN), // false
filter_var(0,FILTER_VALIDATE_BOOLEAN),// false
filter_var(off,FILTER_VALIDATE_BOOLEAN), // false
filter_var(no,FILTER_VALIDATE_BOOLEAN)// false
);
var_dump(
filter_var(7,FILTER_VALIDATE_BOOLEAN), // false
filter_var(garbage,FILTER_VALIDATE_BOOLEAN) // false
);
But fails to keep consistency when i try to distinguish whether value
is boolean or not witch should be the sole role of *VALIDATE* filter:
var_dump(
filter_var(true,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got true, expected true
filter_var(true,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got true, expected true
filter_var(1,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got true, expected true
filter_var(1,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got true, expected true
filter_var(on,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got true, expected true
filter_var(yes,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE))
// got true, expected true
);
var_dump(
filter_var(false,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got NULL, expected false
filter_var(false,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got false, expected false
filter_var(0,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got false, expected false
filter_var(0,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got false, expected false
filter_var(off,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got false, expected false
filter_var(no,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE))
// got false, expected false
);
var_dump(
filter_var(7,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE)),
// got null, expected null
filter_var(garbage,FILTER_VALIDATE_BOOLEAN,array('flags'=FILTER_NULL_ON_FAILURE))
// got null, expected null
);
See that validating true works as expected so dunno why false should
work differently. Also the little bit confusing part of false being
non boolean is just plain wrong.
In summary - please rethink this behaviour or at least fix the
documentation by a) giving above example of all results (to show what is
really to be expected) and b) state this is a validate filter by mistake
but will stay like this because of BC concerns.
Previous Comments:
[2009-09-09 19:55:33] sjo...@php.net
This is exactly according to the documentation:
If FILTER_NULL_ON_FAILURE is set, FALSE is returned only for 0,
false, off, no, and , and NULL is returned for all non-boolean
values.
Note that false is in the list, but false is not. That is, the string
false will give a result, the boolean false will return null.
Non-boolean makes this a little bit confusing.
Note that the goal here is to convert a string to a boolean. Because
false is not a string, filter_var does not consider it valid input.
[2009-09-09 11:25:29] m dot kurzyna at crystalpoint dot pl
#49263 [NEW]: SplObjectStorage fails to serialize references
From: m dot kurzyna at crystalpoint dot pl
Operating system: Linux
PHP version: 5.3.0
PHP Bug Type: SPL related
Bug description: SplObjectStorage fails to serialize references
Description:
splObjectStorage fails to keep objects stored properly when they are
internally referenced (see [obj]= NULL in the dump).
Reproduce code:
---
$o1 = new stdClass;
$o2 = new stdClass;
$s = new splObjectStorage();
$s[$o1] = array('prev' = null, 'next' = $o2);
$s[$o2] = array('prev' = $o1, 'next' = null);
var_dump(unserialize(serialize($s)));
Expected result:
object(SplObjectStorage)#3 (1) {
[storage:SplObjectStorage:private]=
array(2) {
[3696c2e4eec51f06]=
array(2) {
[obj]=
object(stdClass)#1 (0) {
}
[inf]=
array(2) {
[prev]=
NULL
[next]=
object(stdClass)#2 (0) {
}
}
}
[3696c2e7eec51f06]=
array(2) {
[obj]=
object(stdClass)#2 (0) {
}
[inf]=
array(2) {
[prev]=
object(stdClass)#1 (0) {
}
[next]=
NULL
}
}
}
}
Actual result:
--
object(SplObjectStorage)#4 (1) {
[storage:SplObjectStorage:private]=
array(2) {
[3696c2e0eec51f06]=
array(2) {
[obj]=
object(stdClass)#5 (0) {
}
[inf]=
array(2) {
[prev]=
NULL
[next]=
object(stdClass)#6 (0) {
}
}
}
[3696c2e5593811c6]=
array(2) {
[obj]=
NULL
[inf]=
array(2) {
[prev]=
object(stdClass)#5 (0) {
}
[next]=
NULL
}
}
}
}
--
Edit bug report at http://bugs.php.net/?id=49263edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49263r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49263r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49263r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49263r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49263r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49263r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49263r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49263r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49263r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49263r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49263r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49263r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49263r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49263r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49263r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49263r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49263r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49263r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49263r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49263r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49263r=mysqlcfg
#49184 [NEW]: INPUT_SERVER returns NULL for set variables (CLI)
From: m dot kurzyna at crystalpoint dot pl Operating system: Linux PHP version: 5.3.0 PHP Bug Type: Filter related Bug description: INPUT_SERVER returns NULL for set variables (CLI) Description: This is very similar to #44779, however my report regards variables set as environment variables when running CLI. A variable is visible in $_SERVER but INPUT_SERVER returns NULL. Setting via SetEnv in apache and when running as mod_php is fine. Reproduce code: --- ?php var_dump( filter_input(INPUT_SERVER,'ENV_NAME',FILTER_SANITIZE_STRING), $_SERVER['ENV_NAME'] ); ? Expected result: $ ENV_NAME=var php /tmp/t.php string(3) var string(3) var Actual result: -- $ ENV_NAME=var php /tmp/t.php NULL string(3) var -- Edit bug report at http://bugs.php.net/?id=49184edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49184r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49184r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49184r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49184r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49184r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49184r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49184r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49184r=needscript Try newer version: http://bugs.php.net/fix.php?id=49184r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49184r=support Expected behavior: http://bugs.php.net/fix.php?id=49184r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49184r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49184r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49184r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49184r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49184r=dst IIS Stability: http://bugs.php.net/fix.php?id=49184r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49184r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49184r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49184r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49184r=mysqlcfg
#45079 [Com]: --with-config-file-path causes segmentation fault
ID: 45079
Comment by: m dot kurzyna at crystalpoint dot pl
Reported By: m dot kurzyna at crystalpoint dot pl
Status: Feedback
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 5.3CVS-2008-05-23 (snap)
Assigned To: fb-req-jani
New Comment:
Just tried with 2008.07.08 08:30 snap - seems to work fine with values
both quoted and not. Thanks for the fix.
Previous Comments:
[2008-07-06 11:46:32] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
And provide new backtrace generated with that snapshot.
[2008-05-26 20:43:31] m dot kurzyna at crystalpoint dot pl
As for the location - it seems convenient. Dunno if loading it with the
rest of .ini is a good or bad thing - personally I don't see
disadvantages of this except for having to parse one more file and thus
startup performance loss.
This however is irrelevant. I moved browsecap.ini to /tmp and set
browsecap option to new location - it still crashes. However when it
can't find the file it doesn't so it's something specific to this file
that causes the crash.
I've managed to isolate basic test case: it's using quotation for
values:
option=value
crashes, where
option=value
doesn't. This isn't true for configuration ini file - using quotations
has no crash effect as far as I tested.
[2008-05-26 20:11:44] [EMAIL PROTECTED]
Why do you actually have browscap.ini in that directory anyway..? That
sounds like a very bad idea to me, considering it will get loaded as
normal partial php.ini file. Of course it shouldn't cause a crash
though. :)
[2008-05-25 21:58:35] m dot kurzyna at crystalpoint dot pl
Core was generated by `./sapi/cli/php'.
Program terminated with signal 11, Segmentation fault.
[New process 20491]
#0 0x006f76f4 in ini_lex (ini_lval=0x7fffe7d51180) at
/home/users/builder/src/php/n2/Zend/zend_ini_scanner.c:1673
1673yytext[yyleng] = 0;
(gdb) bt
#0 0x006f76f4 in ini_lex (ini_lval=0x7fffe7d51180) at
/home/users/builder/src/php/n2/Zend/zend_ini_scanner.c:1673
#1 0x006f43be in ini_parse () at
/home/users/builder/src/php/n2/Zend/zend_ini_parser.c:1557
#2 0x006f3c36 in zend_parse_ini_file (fh=0x7fffe7d512c0,
unbuffered_errors=1 '\001', scanner_mode=1,
ini_parser_cb=0x620458 php_browscap_parser_cb, arg=0xb2cec0)
at /home/users/builder/src/php/n2/Zend/zend_ini_parser.c:319
#3 0x00620aba in zm_startup_browscap (type=1,
module_number=7)
at /home/users/builder/src/php/n2/ext/standard/browscap.c:198
#4 0x00618005 in zm_startup_basic (type=1, module_number=7)
at
/home/users/builder/src/php/n2/ext/standard/basic_functions.c:4003
#5 0x0072b711 in zend_startup_module_ex (module=0xb55eb0) at
/home/users/builder/src/php/n2/Zend/zend_API.c:1585
#6 0x00733d00 in zend_hash_apply (ht=0xb335a0,
apply_func=0x72b568 zend_startup_module_ex)
at /home/users/builder/src/php/n2/Zend/zend_hash.c:673
#7 0x0072b8f2 in zend_startup_modules () at
/home/users/builder/src/php/n2/Zend/zend_API.c:1634
#8 0x006b1739 in php_module_startup (sf=0xb2b480,
additional_modules=0x0, num_additional_modules=0)
at /home/users/builder/src/php/n2/main/main.c:1898
#9 0x007c326e in php_cli_startup (sapi_module=0xb2b480) at
/home/users/builder/src/php/n2/sapi/cli/php_cli.c:358
#10 0x007c3ffb in main (argc=1, argv=0x7fffe7d51938) at
/home/users/builder/src/php/n2/sapi/cli/php_cli.c:716
[2008-05-23 12:40:17] m dot kurzyna at crystalpoint dot pl
Description:
Configuring build --with-config-file-path=/etc/php causes
segmentation fault when invoking binary (both CLI and CGI).
Reproduce code:
---
./configure --with-config-file-path=/etc/php
make
./sapi/cli/php
Actual result:
--
[EMAIL PROTECTED] n1]$ ./sapi/cgi/php-cgi
Segmentation fault
A strace follows:
[...]
open(/etc/php/php.ini, O_RDONLY) = 3
lstat(/etc, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat(/etc/php, {st_mode=S_IFDIR|0755, st_size=52, ...}) = 0
lstat(/etc/php/php.ini, {st_mode=S_IFREG|0644,
st_size=42387, ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe8ff0d60) = -1 ENOTTY
(Inappropriate ioctl for device)
fstat(3, {st_mode=S_IFREG|0644, st_size=42387, ...}) = 0
mmap(NULL, 42403, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b4dc1b13000
munmap(0x2b4dc1b13000, 42387) = 0
close(3)= 0
mmap(NULL, 323584, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, -1, 0) = 0x2b4dc1b13000
brk(0xa42000
#45079 [Opn]: --with-config-file-path causes segmentation fault
ID: 45079
User updated by: m dot kurzyna at crystalpoint dot pl
Reported By: m dot kurzyna at crystalpoint dot pl
Status: Open
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 5.3CVS-2008-05-23 (snap)
New Comment:
Just tried with current snap (2008.05.11 10:30) - still present.
Previous Comments:
[2008-05-26 20:43:31] m dot kurzyna at crystalpoint dot pl
As for the location - it seems convenient. Dunno if loading it with the
rest of .ini is a good or bad thing - personally I don't see
disadvantages of this except for having to parse one more file and thus
startup performance loss.
This however is irrelevant. I moved browsecap.ini to /tmp and set
browsecap option to new location - it still crashes. However when it
can't find the file it doesn't so it's something specific to this file
that causes the crash.
I've managed to isolate basic test case: it's using quotation for
values:
option=value
crashes, where
option=value
doesn't. This isn't true for configuration ini file - using quotations
has no crash effect as far as I tested.
[2008-05-26 20:11:44] [EMAIL PROTECTED]
Why do you actually have browscap.ini in that directory anyway..? That
sounds like a very bad idea to me, considering it will get loaded as
normal partial php.ini file. Of course it shouldn't cause a crash
though. :)
[2008-05-25 21:58:35] m dot kurzyna at crystalpoint dot pl
Core was generated by `./sapi/cli/php'.
Program terminated with signal 11, Segmentation fault.
[New process 20491]
#0 0x006f76f4 in ini_lex (ini_lval=0x7fffe7d51180) at
/home/users/builder/src/php/n2/Zend/zend_ini_scanner.c:1673
1673yytext[yyleng] = 0;
(gdb) bt
#0 0x006f76f4 in ini_lex (ini_lval=0x7fffe7d51180) at
/home/users/builder/src/php/n2/Zend/zend_ini_scanner.c:1673
#1 0x006f43be in ini_parse () at
/home/users/builder/src/php/n2/Zend/zend_ini_parser.c:1557
#2 0x006f3c36 in zend_parse_ini_file (fh=0x7fffe7d512c0,
unbuffered_errors=1 '\001', scanner_mode=1,
ini_parser_cb=0x620458 php_browscap_parser_cb, arg=0xb2cec0)
at /home/users/builder/src/php/n2/Zend/zend_ini_parser.c:319
#3 0x00620aba in zm_startup_browscap (type=1,
module_number=7)
at /home/users/builder/src/php/n2/ext/standard/browscap.c:198
#4 0x00618005 in zm_startup_basic (type=1, module_number=7)
at
/home/users/builder/src/php/n2/ext/standard/basic_functions.c:4003
#5 0x0072b711 in zend_startup_module_ex (module=0xb55eb0) at
/home/users/builder/src/php/n2/Zend/zend_API.c:1585
#6 0x00733d00 in zend_hash_apply (ht=0xb335a0,
apply_func=0x72b568 zend_startup_module_ex)
at /home/users/builder/src/php/n2/Zend/zend_hash.c:673
#7 0x0072b8f2 in zend_startup_modules () at
/home/users/builder/src/php/n2/Zend/zend_API.c:1634
#8 0x006b1739 in php_module_startup (sf=0xb2b480,
additional_modules=0x0, num_additional_modules=0)
at /home/users/builder/src/php/n2/main/main.c:1898
#9 0x007c326e in php_cli_startup (sapi_module=0xb2b480) at
/home/users/builder/src/php/n2/sapi/cli/php_cli.c:358
#10 0x007c3ffb in main (argc=1, argv=0x7fffe7d51938) at
/home/users/builder/src/php/n2/sapi/cli/php_cli.c:716
[2008-05-23 12:40:17] m dot kurzyna at crystalpoint dot pl
Description:
Configuring build --with-config-file-path=/etc/php causes
segmentation fault when invoking binary (both CLI and CGI).
Reproduce code:
---
./configure --with-config-file-path=/etc/php
make
./sapi/cli/php
Actual result:
--
[EMAIL PROTECTED] n1]$ ./sapi/cgi/php-cgi
Segmentation fault
A strace follows:
[...]
open(/etc/php/php.ini, O_RDONLY) = 3
lstat(/etc, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat(/etc/php, {st_mode=S_IFDIR|0755, st_size=52, ...}) = 0
lstat(/etc/php/php.ini, {st_mode=S_IFREG|0644,
st_size=42387, ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe8ff0d60) = -1 ENOTTY
(Inappropriate ioctl for device)
fstat(3, {st_mode=S_IFREG|0644, st_size=42387, ...}) = 0
mmap(NULL, 42403, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b4dc1b13000
munmap(0x2b4dc1b13000, 42387) = 0
close(3)= 0
mmap(NULL, 323584, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, -1, 0) = 0x2b4dc1b13000
brk(0xa42000) = 0xa42000
brk(0xa63000) = 0xa63000
brk(0xa84000) = 0xa84000
futex(0x2b4dc2d11ae0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
brk(0xaa5000) = 0xaa5000
brk(0xac6000) = 0xac6000
brk(0xae7000) = 0xae7000
brk
#45079 [Opn]: --with-config-file-path causes segmentation fault
ID: 45079
User updated by: m dot kurzyna at crystalpoint dot pl
Reported By: m dot kurzyna at crystalpoint dot pl
Status: Open
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 5.3CVS-2008-05-23 (snap)
New Comment:
Ofc 2008.06.11 10:30 - just a typo.
Previous Comments:
[2008-06-11 12:32:46] m dot kurzyna at crystalpoint dot pl
Just tried with current snap (2008.05.11 10:30) - still present.
[2008-05-26 20:43:31] m dot kurzyna at crystalpoint dot pl
As for the location - it seems convenient. Dunno if loading it with the
rest of .ini is a good or bad thing - personally I don't see
disadvantages of this except for having to parse one more file and thus
startup performance loss.
This however is irrelevant. I moved browsecap.ini to /tmp and set
browsecap option to new location - it still crashes. However when it
can't find the file it doesn't so it's something specific to this file
that causes the crash.
I've managed to isolate basic test case: it's using quotation for
values:
option=value
crashes, where
option=value
doesn't. This isn't true for configuration ini file - using quotations
has no crash effect as far as I tested.
[2008-05-26 20:11:44] [EMAIL PROTECTED]
Why do you actually have browscap.ini in that directory anyway..? That
sounds like a very bad idea to me, considering it will get loaded as
normal partial php.ini file. Of course it shouldn't cause a crash
though. :)
[2008-05-25 21:58:35] m dot kurzyna at crystalpoint dot pl
Core was generated by `./sapi/cli/php'.
Program terminated with signal 11, Segmentation fault.
[New process 20491]
#0 0x006f76f4 in ini_lex (ini_lval=0x7fffe7d51180) at
/home/users/builder/src/php/n2/Zend/zend_ini_scanner.c:1673
1673yytext[yyleng] = 0;
(gdb) bt
#0 0x006f76f4 in ini_lex (ini_lval=0x7fffe7d51180) at
/home/users/builder/src/php/n2/Zend/zend_ini_scanner.c:1673
#1 0x006f43be in ini_parse () at
/home/users/builder/src/php/n2/Zend/zend_ini_parser.c:1557
#2 0x006f3c36 in zend_parse_ini_file (fh=0x7fffe7d512c0,
unbuffered_errors=1 '\001', scanner_mode=1,
ini_parser_cb=0x620458 php_browscap_parser_cb, arg=0xb2cec0)
at /home/users/builder/src/php/n2/Zend/zend_ini_parser.c:319
#3 0x00620aba in zm_startup_browscap (type=1,
module_number=7)
at /home/users/builder/src/php/n2/ext/standard/browscap.c:198
#4 0x00618005 in zm_startup_basic (type=1, module_number=7)
at
/home/users/builder/src/php/n2/ext/standard/basic_functions.c:4003
#5 0x0072b711 in zend_startup_module_ex (module=0xb55eb0) at
/home/users/builder/src/php/n2/Zend/zend_API.c:1585
#6 0x00733d00 in zend_hash_apply (ht=0xb335a0,
apply_func=0x72b568 zend_startup_module_ex)
at /home/users/builder/src/php/n2/Zend/zend_hash.c:673
#7 0x0072b8f2 in zend_startup_modules () at
/home/users/builder/src/php/n2/Zend/zend_API.c:1634
#8 0x006b1739 in php_module_startup (sf=0xb2b480,
additional_modules=0x0, num_additional_modules=0)
at /home/users/builder/src/php/n2/main/main.c:1898
#9 0x007c326e in php_cli_startup (sapi_module=0xb2b480) at
/home/users/builder/src/php/n2/sapi/cli/php_cli.c:358
#10 0x007c3ffb in main (argc=1, argv=0x7fffe7d51938) at
/home/users/builder/src/php/n2/sapi/cli/php_cli.c:716
[2008-05-23 12:40:17] m dot kurzyna at crystalpoint dot pl
Description:
Configuring build --with-config-file-path=/etc/php causes
segmentation fault when invoking binary (both CLI and CGI).
Reproduce code:
---
./configure --with-config-file-path=/etc/php
make
./sapi/cli/php
Actual result:
--
[EMAIL PROTECTED] n1]$ ./sapi/cgi/php-cgi
Segmentation fault
A strace follows:
[...]
open(/etc/php/php.ini, O_RDONLY) = 3
lstat(/etc, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat(/etc/php, {st_mode=S_IFDIR|0755, st_size=52, ...}) = 0
lstat(/etc/php/php.ini, {st_mode=S_IFREG|0644,
st_size=42387, ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe8ff0d60) = -1 ENOTTY
(Inappropriate ioctl for device)
fstat(3, {st_mode=S_IFREG|0644, st_size=42387, ...}) = 0
mmap(NULL, 42403, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b4dc1b13000
munmap(0x2b4dc1b13000, 42387) = 0
close(3)= 0
mmap(NULL, 323584, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, -1, 0) = 0x2b4dc1b13000
brk(0xa42000) = 0xa42000
brk(0xa63000) = 0xa63000
brk(0xa84000) = 0xa84000
futex(0x2b4dc2d11ae0, FUTEX_WAKE_PRIVATE
#45079 [Fbk-Opn]: with-config-file-path causes segmentation fault
ID: 45079
User updated by: m dot kurzyna at crystalpoint dot pl
Reported By: m dot kurzyna at crystalpoint dot pl
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 5.3CVS-2008-05-23 (snap)
New Comment:
Core was generated by `./sapi/cli/php'.
Program terminated with signal 11, Segmentation fault.
[New process 20491]
#0 0x006f76f4 in ini_lex (ini_lval=0x7fffe7d51180) at
/home/users/builder/src/php/n2/Zend/zend_ini_scanner.c:1673
1673yytext[yyleng] = 0;
(gdb) bt
#0 0x006f76f4 in ini_lex (ini_lval=0x7fffe7d51180) at
/home/users/builder/src/php/n2/Zend/zend_ini_scanner.c:1673
#1 0x006f43be in ini_parse () at
/home/users/builder/src/php/n2/Zend/zend_ini_parser.c:1557
#2 0x006f3c36 in zend_parse_ini_file (fh=0x7fffe7d512c0,
unbuffered_errors=1 '\001', scanner_mode=1,
ini_parser_cb=0x620458 php_browscap_parser_cb, arg=0xb2cec0)
at /home/users/builder/src/php/n2/Zend/zend_ini_parser.c:319
#3 0x00620aba in zm_startup_browscap (type=1,
module_number=7)
at /home/users/builder/src/php/n2/ext/standard/browscap.c:198
#4 0x00618005 in zm_startup_basic (type=1, module_number=7)
at
/home/users/builder/src/php/n2/ext/standard/basic_functions.c:4003
#5 0x0072b711 in zend_startup_module_ex (module=0xb55eb0) at
/home/users/builder/src/php/n2/Zend/zend_API.c:1585
#6 0x00733d00 in zend_hash_apply (ht=0xb335a0,
apply_func=0x72b568 zend_startup_module_ex)
at /home/users/builder/src/php/n2/Zend/zend_hash.c:673
#7 0x0072b8f2 in zend_startup_modules () at
/home/users/builder/src/php/n2/Zend/zend_API.c:1634
#8 0x006b1739 in php_module_startup (sf=0xb2b480,
additional_modules=0x0, num_additional_modules=0)
at /home/users/builder/src/php/n2/main/main.c:1898
#9 0x007c326e in php_cli_startup (sapi_module=0xb2b480) at
/home/users/builder/src/php/n2/sapi/cli/php_cli.c:358
#10 0x007c3ffb in main (argc=1, argv=0x7fffe7d51938) at
/home/users/builder/src/php/n2/sapi/cli/php_cli.c:716
Previous Comments:
[2008-05-25 18:33:25] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
[2008-05-23 12:40:17] m dot kurzyna at crystalpoint dot pl
Description:
Configuring build --with-config-file-path=/etc/php causes
segmentation fault when invoking binary (both CLI and CGI).
Reproduce code:
---
./configure --with-config-file-path=/etc/php
make
./sapi/cli/php
Actual result:
--
[EMAIL PROTECTED] n1]$ ./sapi/cgi/php-cgi
Segmentation fault
A strace follows:
[...]
open(/etc/php/php.ini, O_RDONLY) = 3
lstat(/etc, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat(/etc/php, {st_mode=S_IFDIR|0755, st_size=52, ...}) = 0
lstat(/etc/php/php.ini, {st_mode=S_IFREG|0644,
st_size=42387, ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe8ff0d60) = -1 ENOTTY
(Inappropriate ioctl for device)
fstat(3, {st_mode=S_IFREG|0644, st_size=42387, ...}) = 0
mmap(NULL, 42403, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b4dc1b13000
munmap(0x2b4dc1b13000, 42387) = 0
close(3)= 0
mmap(NULL, 323584, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, -1, 0) = 0x2b4dc1b13000
brk(0xa42000) = 0xa42000
brk(0xa63000) = 0xa63000
brk(0xa84000) = 0xa84000
futex(0x2b4dc2d11ae0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
brk(0xaa5000) = 0xaa5000
brk(0xac6000) = 0xac6000
brk(0xae7000) = 0xae7000
brk(0xb08000) = 0xb08000
brk(0xb29000) = 0xb29000
open(/etc/php/browscap.ini, O_RDONLY) = 3
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe8ff1da0) = -1 ENOTTY
(Inappropriate ioctl for device)
fstat(3, {st_mode=S_IFREG|0644, st_size=319838, ...}) = 0
mmap(NULL, 319854, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b4dc1b62000
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
--
Edit this bug report at http://bugs.php.net/?id=45079edit=1
#45079 [NEW]: with-config-file-path causes segmentation fault
From: m dot kurzyna at crystalpoint dot pl
Operating system: Linux
PHP version: 5.3CVS-2008-05-23 (snap)
PHP Bug Type: *Compile Issues
Bug description: with-config-file-path causes segmentation fault
Description:
Configuring build --with-config-file-path=/etc/php causes
segmentation fault when invoking binary (both CLI and CGI).
Reproduce code:
---
./configure --with-config-file-path=/etc/php
make
./sapi/cli/php
Actual result:
--
[EMAIL PROTECTED] n1]$ ./sapi/cgi/php-cgi
Segmentation fault
A strace follows:
[...]
open(/etc/php/php.ini, O_RDONLY) = 3
lstat(/etc, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat(/etc/php, {st_mode=S_IFDIR|0755, st_size=52, ...}) = 0
lstat(/etc/php/php.ini, {st_mode=S_IFREG|0644,
st_size=42387, ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe8ff0d60) = -1 ENOTTY
(Inappropriate ioctl for device)
fstat(3, {st_mode=S_IFREG|0644, st_size=42387, ...}) = 0
mmap(NULL, 42403, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b4dc1b13000
munmap(0x2b4dc1b13000, 42387) = 0
close(3)= 0
mmap(NULL, 323584, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, -1, 0) = 0x2b4dc1b13000
brk(0xa42000) = 0xa42000
brk(0xa63000) = 0xa63000
brk(0xa84000) = 0xa84000
futex(0x2b4dc2d11ae0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
brk(0xaa5000) = 0xaa5000
brk(0xac6000) = 0xac6000
brk(0xae7000) = 0xae7000
brk(0xb08000) = 0xb08000
brk(0xb29000) = 0xb29000
open(/etc/php/browscap.ini, O_RDONLY) = 3
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe8ff1da0) = -1 ENOTTY
(Inappropriate ioctl for device)
fstat(3, {st_mode=S_IFREG|0644, st_size=319838, ...}) = 0
mmap(NULL, 319854, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b4dc1b62000
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
--
Edit bug report at http://bugs.php.net/?id=45079edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45079r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45079r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45079r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45079r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45079r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45079r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45079r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45079r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45079r=support
Expected behavior:http://bugs.php.net/fix.php?id=45079r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45079r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45079r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45079r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45079r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45079r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45079r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45079r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45079r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45079r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45079r=mysqlcfg
#44315 [NEW]: Late static binding not working for variables
From: m dot kurzyna at crystalpoint dot pl
Operating system: PLD Linux
PHP version: 5.3CVS-2008-03-03 (snap)
PHP Bug Type: Scripting Engine problem
Bug description: Late static binding not working for variables
Description:
Late static binding doesn't seem to apply to static class variables.
Example is rather self explanatory (construtor using static keyword
should increment variable in calling class).
Reproduce code:
---
?php
class B {
static protected $counter = 0;
public function __construct() {
++static::$counter;
var_dump(static::$counter);
}
}
class C extends B {
public function __construct() {
++static::$counter;
var_dump(static::$counter);
}
}
new B;
new C;
?
Expected result:
int(1)
int(1)
Actual result:
--
int(1)
int(2)
--
Edit bug report at http://bugs.php.net/?id=44315edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44315r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44315r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44315r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44315r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44315r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44315r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44315r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44315r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44315r=support
Expected behavior:http://bugs.php.net/fix.php?id=44315r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44315r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44315r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44315r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44315r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44315r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44315r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44315r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44315r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44315r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44315r=mysqlcfg
#44315 [Opn]: Late static binding not working for variables
ID: 44315
User updated by: m dot kurzyna at crystalpoint dot pl
Reported By: m dot kurzyna at crystalpoint dot pl
Status: Open
Bug Type: Scripting Engine problem
Operating System: PLD Linux
PHP Version: 5.3CVS-2008-03-03 (snap)
New Comment:
The snapshot used was php-5.3-2008-03-02-21:30.
Previous Comments:
[2008-03-03 01:18:47] m dot kurzyna at crystalpoint dot pl
Description:
Late static binding doesn't seem to apply to static class variables.
Example is rather self explanatory (construtor using static keyword
should increment variable in calling class).
Reproduce code:
---
?php
class B {
static protected $counter = 0;
public function __construct() {
++static::$counter;
var_dump(static::$counter);
}
}
class C extends B {
public function __construct() {
++static::$counter;
var_dump(static::$counter);
}
}
new B;
new C;
?
Expected result:
int(1)
int(1)
Actual result:
--
int(1)
int(2)
--
Edit this bug report at http://bugs.php.net/?id=44315edit=1
#44315 [Bgs]: Late static binding not working for variables
ID: 44315
User updated by: m dot kurzyna at crystalpoint dot pl
Reported By: m dot kurzyna at crystalpoint dot pl
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: PLD Linux
PHP Version: 5.3CVS-2008-03-03 (snap)
New Comment:
Hm.. ok. My bad. Thanks for the extra info.
Previous Comments:
[2008-03-03 01:38:51] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
in C::__construct, static resolves to C, and C::$counter is not defined
per-se, a fallback occurs and B::$counter is incremented. Nothing to do
with late static bindings.
[2008-03-03 01:31:17] m dot kurzyna at crystalpoint dot pl
The snapshot used was php-5.3-2008-03-02-21:30.
[2008-03-03 01:18:47] m dot kurzyna at crystalpoint dot pl
Description:
Late static binding doesn't seem to apply to static class variables.
Example is rather self explanatory (construtor using static keyword
should increment variable in calling class).
Reproduce code:
---
?php
class B {
static protected $counter = 0;
public function __construct() {
++static::$counter;
var_dump(static::$counter);
}
}
class C extends B {
public function __construct() {
++static::$counter;
var_dump(static::$counter);
}
}
new B;
new C;
?
Expected result:
int(1)
int(1)
Actual result:
--
int(1)
int(2)
--
Edit this bug report at http://bugs.php.net/?id=44315edit=1
#38785 [Opn]: float to string cast is always subject to locale settings
ID: 38785 User updated by: m dot kurzyna at crystalpoint dot pl -Summary: stripslashes is setlocale aware - decimal point conversion Reported By: m dot kurzyna at crystalpoint dot pl Status: Open -Bug Type: Documentation problem +Bug Type: *Languages/Translation Operating System: Linux -PHP Version: Irrelevant +PHP Version: 5.6.1 New Comment: This behaviour is more general - it applyes to any float to string conversion wether it's explicit or implicit. There are some bugreports on this already though all are bound to some concrete functions. Previous Comments: [2006-09-11 23:35:49] m dot kurzyna at crystalpoint dot pl Description: Stripslashes seems to be locale specific. It changes decimal point character when used in enviroment with locales set. I'm not shure is this a feature or a bug but it's something unexpected as it's not mensioned in the manual as far as I know. And it's easy to criple database input with this. As a locale to observe this behaviour one can set probably enything that uses comma rather then dot for decimal point. Reproduce code: --- $float = 0.10; // $float is now float 0.10 setlocale(LC_ALL,'C'); $r = stripslashes($float); // $r is now string 0.10 setlocale(LC_ALL,'pl_PL'); $r = stripslashes($float); // $r is now string 0,10 Expected result: No change in decimalpoint or explicit note in documentation. Actual result: -- Provided in code example - change of decimal point character. -- Edit this bug report at http://bugs.php.net/?id=38785edit=1
#38785 [Opn]: float to string cast is always subject to locale settings
ID: 38785 User updated by: m dot kurzyna at crystalpoint dot pl Reported By: m dot kurzyna at crystalpoint dot pl Status: Open Bug Type: *Languages/Translation Operating System: Linux -PHP Version: 5.6.1 +PHP Version: 5.1.6 New Comment: Wrong version in prevous comment. Previous Comments: [2006-09-12 00:04:46] m dot kurzyna at crystalpoint dot pl This behaviour is more general - it applyes to any float to string conversion wether it's explicit or implicit. There are some bugreports on this already though all are bound to some concrete functions. [2006-09-11 23:35:49] m dot kurzyna at crystalpoint dot pl Description: Stripslashes seems to be locale specific. It changes decimal point character when used in enviroment with locales set. I'm not shure is this a feature or a bug but it's something unexpected as it's not mensioned in the manual as far as I know. And it's easy to criple database input with this. As a locale to observe this behaviour one can set probably enything that uses comma rather then dot for decimal point. Reproduce code: --- $float = 0.10; // $float is now float 0.10 setlocale(LC_ALL,'C'); $r = stripslashes($float); // $r is now string 0.10 setlocale(LC_ALL,'pl_PL'); $r = stripslashes($float); // $r is now string 0,10 Expected result: No change in decimalpoint or explicit note in documentation. Actual result: -- Provided in code example - change of decimal point character. -- Edit this bug report at http://bugs.php.net/?id=38785edit=1
#37386 [NEW]: autocreating element doesn't assign value to first node
From: m dot kurzyna at crystalpoint dot pl Operating system: Linux PHP version: 5.1.4 PHP Bug Type: SimpleXML related Bug description: autocreating element doesn't assign value to first node Description: If autocreating new nodes by id ($obj-node[0] = '') SimpleXML doesn't assign value to first node. Creating first node w/o using id works fine. Reproduce code: --- ?php $sx1 = new SimpleXMLElement(root /); $sx1-node[0] = 'node1'; $sx1-node[1] = 'node2'; ? Expected result: object(SimpleXMLElement)[1] public 'node' = array 0 = 'node1' (length=5) 1 = 'node2' (length=5) Actual result: -- object(SimpleXMLElement)[1] public 'node' = array 0 = object(SimpleXMLElement)[6] 1 = 'node2' (length=5) -- Edit bug report at http://bugs.php.net/?id=37386edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37386r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=37386r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37386r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37386r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37386r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37386r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37386r=needscript Try newer version:http://bugs.php.net/fix.php?id=37386r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37386r=support Expected behavior:http://bugs.php.net/fix.php?id=37386r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37386r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37386r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37386r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37386r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37386r=dst IIS Stability:http://bugs.php.net/fix.php?id=37386r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37386r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37386r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37386r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37386r=mysqlcfg
