[PHP-BUG] Bug #64192 [NEW]: function array_splice() wrong result
From: italopaesano at gmail dot com
Operating system: linux
PHP version: 5.3.21
Package: *General Issues
Bug Type: Bug
Bug description:function array_splice() wrong result
Description:
function array_splice()
return wrong result when splice multidimensional array.
i hope that the attached script is clear.
sorry for my english.
Test script:
---
$a = array();
$a[] = array(
'start' => array('day' => '1','month '=> '2'),
'end' => array('day'=> '3','month'=> '2'));
$a[] = array(
'start' => array('day' => '1','month '=> '3'),
'end' => array('day'=> '3','month'=> '3'));
$strip = array(
'start' => array('day' => '11','month '=> '1'),
'end' => array('day'=> '14','month'=> '1'));
array_splice($a, 0, 1, $strip);
$temp = print_r($a,TRUE);
$temp = str_replace("\n", '', $temp);
echo str_replace(" ", " ",$temp);
Expected result:
Array
(
[0] => Array
(
[start] => Array
(
[day] => 11
[month ] => 1
)
[end] => Array
(
[day] => 14
[month] => 1
)
)
[1] => Array
(
[start] => Array
(
[day] => 1
[month ] => 3
)
[end] => Array
(
[day] => 3
[month] => 3
)
)
)
Actual result:
--
Array
(
[0] => Array
(
[day] => 11
[month ] => 1
)
[1] => Array
(
[day] => 14
[month] => 1
)
[2] => Array
(
[start] => Array
(
[day] => 1
[month ] => 3
)
[end] => Array
(
[day] => 3
[month] => 3
)
)
)
--
Edit bug report at https://bugs.php.net/bug.php?id=64192&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64192&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64192&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64192&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64192&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64192&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64192&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64192&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64192&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64192&r=support
Expected behavior: https://bugs.php.net/fix.php?id=64192&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64192&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64192&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64192&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64192&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64192&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64192&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64192&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64192&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64192&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64192&r=mysqlcfg
Req #64184 [Wfx]: Enhance the -l (Lint) command line option
Edit report at https://bugs.php.net/bug.php?id=64184&edit=1 ID: 64184 Updated by: ras...@php.net Reported by:andyearnshaw at gmail dot com Summary:Enhance the -l (Lint) command line option Status: Wont fix Type: Feature/Change Request Package:*General Issues Operating System: Any PHP Version:Irrelevant Block user comment: N Private report: N New Comment: It's not like there are a lot of them to read: Mar 2012 PHP 5.4 Jun 2009 PHP 5.3 Nov 2006 PHP 5.2 Nov 2005 PHP 5.1 Jul 2004 PHP 5.0 So 5 of them in the past 9 years or so. We don't deprecate anything in the point releases between these. Previous Comments: [2013-02-11 23:45:19] andyearnshaw at gmail dot com I could, but then there's the problem of reading a backlog of upgrading documents when I don't religiously update PHP, and also the issue of remembering which functions are deprecated and which aren't at the time of programming without checking the docs :-) However, I do understand that this is beyond the scope of the compiler and, therefore, the -l command line option. [2013-02-11 23:41:37] ras...@php.net You could read the UPGRADING doc we provide with every new release. [2013-02-11 23:38:24] andyearnshaw at gmail dot com That's a shame. One of the annoying things about not keeping up with every single PHP release is that you don't know things are deprecated until you've spent time developing and then check the error logs during the testing phase. Then you have to either spend time rewriting the code or live with using deprecated functions for a while. [2013-02-11 23:33:23] ras...@php.net That would require writing a static analyzer which is outside our scope at this point. Right now it simply runs the compile-phase and none of the things you are asking for can be done by the compiler. The executor can do some of this, but not without actually executing the script, which you don't want. The closest thing to a full static analyzer is Facebook's HipHop project if you run it in analyze-only mode. [2013-02-10 13:27:23] andyearnshaw at gmail dot com Description: It would be great if the command line -l option could be enhanced to do more than just syntax checking. It would be infinitely more useful if it could also output warnings for the following: - Use of deprecated functions - Correct number of function arguments - Other useful warnings (creating default object from empty value, etc) - Optionally, best practices This would make it more akin to the JavaScript linters available, with the added benefit of always being relevant to the version of PHP installed. -- Edit this bug report at https://bugs.php.net/bug.php?id=64184&edit=1
Req #64184 [Wfx]: Enhance the -l (Lint) command line option
Edit report at https://bugs.php.net/bug.php?id=64184&edit=1 ID: 64184 User updated by:andyearnshaw at gmail dot com Reported by:andyearnshaw at gmail dot com Summary:Enhance the -l (Lint) command line option Status: Wont fix Type: Feature/Change Request Package:*General Issues Operating System: Any PHP Version:Irrelevant Block user comment: N Private report: N New Comment: I could, but then there's the problem of reading a backlog of upgrading documents when I don't religiously update PHP, and also the issue of remembering which functions are deprecated and which aren't at the time of programming without checking the docs :-) However, I do understand that this is beyond the scope of the compiler and, therefore, the -l command line option. Previous Comments: [2013-02-11 23:41:37] ras...@php.net You could read the UPGRADING doc we provide with every new release. [2013-02-11 23:38:24] andyearnshaw at gmail dot com That's a shame. One of the annoying things about not keeping up with every single PHP release is that you don't know things are deprecated until you've spent time developing and then check the error logs during the testing phase. Then you have to either spend time rewriting the code or live with using deprecated functions for a while. [2013-02-11 23:33:23] ras...@php.net That would require writing a static analyzer which is outside our scope at this point. Right now it simply runs the compile-phase and none of the things you are asking for can be done by the compiler. The executor can do some of this, but not without actually executing the script, which you don't want. The closest thing to a full static analyzer is Facebook's HipHop project if you run it in analyze-only mode. [2013-02-10 13:27:23] andyearnshaw at gmail dot com Description: It would be great if the command line -l option could be enhanced to do more than just syntax checking. It would be infinitely more useful if it could also output warnings for the following: - Use of deprecated functions - Correct number of function arguments - Other useful warnings (creating default object from empty value, etc) - Optionally, best practices This would make it more akin to the JavaScript linters available, with the added benefit of always being relevant to the version of PHP installed. -- Edit this bug report at https://bugs.php.net/bug.php?id=64184&edit=1
Req #64184 [Wfx]: Enhance the -l (Lint) command line option
Edit report at https://bugs.php.net/bug.php?id=64184&edit=1 ID: 64184 Updated by: ras...@php.net Reported by:andyearnshaw at gmail dot com Summary:Enhance the -l (Lint) command line option Status: Wont fix Type: Feature/Change Request Package:*General Issues Operating System: Any PHP Version:Irrelevant Block user comment: N Private report: N New Comment: You could read the UPGRADING doc we provide with every new release. Previous Comments: [2013-02-11 23:38:24] andyearnshaw at gmail dot com That's a shame. One of the annoying things about not keeping up with every single PHP release is that you don't know things are deprecated until you've spent time developing and then check the error logs during the testing phase. Then you have to either spend time rewriting the code or live with using deprecated functions for a while. [2013-02-11 23:33:23] ras...@php.net That would require writing a static analyzer which is outside our scope at this point. Right now it simply runs the compile-phase and none of the things you are asking for can be done by the compiler. The executor can do some of this, but not without actually executing the script, which you don't want. The closest thing to a full static analyzer is Facebook's HipHop project if you run it in analyze-only mode. [2013-02-10 13:27:23] andyearnshaw at gmail dot com Description: It would be great if the command line -l option could be enhanced to do more than just syntax checking. It would be infinitely more useful if it could also output warnings for the following: - Use of deprecated functions - Correct number of function arguments - Other useful warnings (creating default object from empty value, etc) - Optionally, best practices This would make it more akin to the JavaScript linters available, with the added benefit of always being relevant to the version of PHP installed. -- Edit this bug report at https://bugs.php.net/bug.php?id=64184&edit=1
Req #64184 [Wfx]: Enhance the -l (Lint) command line option
Edit report at https://bugs.php.net/bug.php?id=64184&edit=1 ID: 64184 User updated by:andyearnshaw at gmail dot com Reported by:andyearnshaw at gmail dot com Summary:Enhance the -l (Lint) command line option Status: Wont fix Type: Feature/Change Request Package:*General Issues Operating System: Any PHP Version:Irrelevant Block user comment: N Private report: N New Comment: That's a shame. One of the annoying things about not keeping up with every single PHP release is that you don't know things are deprecated until you've spent time developing and then check the error logs during the testing phase. Then you have to either spend time rewriting the code or live with using deprecated functions for a while. Previous Comments: [2013-02-11 23:33:23] ras...@php.net That would require writing a static analyzer which is outside our scope at this point. Right now it simply runs the compile-phase and none of the things you are asking for can be done by the compiler. The executor can do some of this, but not without actually executing the script, which you don't want. The closest thing to a full static analyzer is Facebook's HipHop project if you run it in analyze-only mode. [2013-02-10 13:27:23] andyearnshaw at gmail dot com Description: It would be great if the command line -l option could be enhanced to do more than just syntax checking. It would be infinitely more useful if it could also output warnings for the following: - Use of deprecated functions - Correct number of function arguments - Other useful warnings (creating default object from empty value, etc) - Optionally, best practices This would make it more akin to the JavaScript linters available, with the added benefit of always being relevant to the version of PHP installed. -- Edit this bug report at https://bugs.php.net/bug.php?id=64184&edit=1
Req #64184 [Opn->Wfx]: Enhance the -l (Lint) command line option
Edit report at https://bugs.php.net/bug.php?id=64184&edit=1 ID: 64184 Updated by: ras...@php.net Reported by:andyearnshaw at gmail dot com Summary:Enhance the -l (Lint) command line option -Status: Open +Status: Wont fix Type: Feature/Change Request Package:*General Issues Operating System: Any PHP Version:Irrelevant Block user comment: N Private report: N New Comment: That would require writing a static analyzer which is outside our scope at this point. Right now it simply runs the compile-phase and none of the things you are asking for can be done by the compiler. The executor can do some of this, but not without actually executing the script, which you don't want. The closest thing to a full static analyzer is Facebook's HipHop project if you run it in analyze-only mode. Previous Comments: [2013-02-10 13:27:23] andyearnshaw at gmail dot com Description: It would be great if the command line -l option could be enhanced to do more than just syntax checking. It would be infinitely more useful if it could also output warnings for the following: - Use of deprecated functions - Correct number of function arguments - Other useful warnings (creating default object from empty value, etc) - Optionally, best practices This would make it more akin to the JavaScript linters available, with the added benefit of always being relevant to the version of PHP installed. -- Edit this bug report at https://bugs.php.net/bug.php?id=64184&edit=1
Bug #64187 [Com]: CGI/FastCGI truncates input to modulo 4GB
Edit report at https://bugs.php.net/bug.php?id=64187&edit=1
ID: 64187
Comment by: nachms+php at gmail dot com
Reported by:nachms+php at gmail dot com
Summary:CGI/FastCGI truncates input to modulo 4GB
Status: Open
Type: Bug
Package:Streams related
Operating System: Linux
PHP Version:5.4.11
Block user comment: N
Private report: N
New Comment:
Due to lack of comments as mentioned above, I'm unsure what the problematic
loop is needed for. However thinking more about it, perhaps it's needed for
pipelining or multiplexing?
In which case, changing read_post_bytes in SAPI.h from int to long, and
removing the uint cast from SG(request_info).content_length may be the correct
solution.
Previous Comments:
[2013-02-11 10:11:29] nachms+php at gmail dot com
In cgi_main.c, in sapi_cgi_read_post() and sapi_fcgi_read_post(), I found if I
comment out the line: count_bytes = MIN(count_bytes, (uint)
SG(request_info).content_length - SG(read_post_bytes));
Then the bug is fixed.
I'm not sure why the amount of bytes going to be read is bounded to
read_post_bytes subtracted from the length. read() will only read the amount
that it can, and it doesn't matter if you asked for too much, it will return
what is available.
For FastCGI, I'm not familiar enough with fcgi_read() enough to know if the
lack of bounding causes a problem or not. However, mod_php5 as an example
doesn't bound it. And if bounding is needed, this code needs to make use of
long or unsigned long instead of int and unit.
[2013-02-11 02:37:29] nachms+php at gmail dot com
I think I found the bug in cgi_main.c:
static int sapi_cgi_read_post(char *buffer, uint count_bytes TSRMLS_DC)
{
uint read_bytes = 0;
int tmp_read_bytes;
count_bytes = MIN(count_bytes, (uint) SG(request_info).content_length -
SG(read_post_bytes));
while (read_bytes < count_bytes) {
tmp_read_bytes = read(STDIN_FILENO, buffer + read_bytes,
count_bytes - read_bytes);
if (tmp_read_bytes <= 0) {
break;
}
read_bytes += tmp_read_bytes;
}
return read_bytes;
}
It looks like content_length, a long, is being truncated to a uint. I'll look
into fixing this based on what mod_php5 does.
[2013-02-11 01:57:46] nachms+php at gmail dot com
Description:
I've tested sending huge amounts of data via PUT to PHP from 5.3.x through
5.4.x via CGI, FastCGI, and mod_php for Apache, all on AMD64.
In all my tests, mod_php with Apache seems to be fine. However via CGI or
FastCGI, PHP can only see the amount of data modulo 4294967296. Which seems to
indicate that somewhere an int instead of a long is used in the the CGI
processing code, but so far, I have been unable to find where exactly. All my
builds are 64-bit, so that's not the issue.
To elaborate, via mod_php, if I send via HTTP PUT 4296015872 bytes, then PHP
will see all of them. However, via CGI or FastCGI, PHP will only see 1048576
bytes.
Test script:
---
http://paste.nachsoftware.com/Nach/TXmPR8289646bbb54bf40ce295115111acde1eYP
//Test via CGI (with FastCGI sharing results)
http://paste.nachsoftware.com/Nach/MXNpV4ec2e499fc0941773aff51184e6e618d2lN
Expected result:
When tested with either of my C test programs, I expect to see 4296015872
listed as the amount read.
Actual result:
--
With mod_php in Apache, I see 4296015872 which is correct. But with
CGI/FastCGI, I see 1048576 as the amount read, which is 4296015872%4294967296,
which indicates, somewhere a long is being converted to an int within the
CGI/FastCGI code.
--
Edit this bug report at https://bugs.php.net/bug.php?id=64187&edit=1
Bug #64181 [Com]: Incorrect value for DateTime "this week" start
Edit report at https://bugs.php.net/bug.php?id=64181&edit=1
ID: 64181
Comment by: timakeeling at gmail dot com
Reported by:grey2k at gmail dot com
Summary:Incorrect value for DateTime "this week" start
Status: Open
Type: Bug
Package:Date/time related
Operating System: Linux and Windows
PHP Version:5.3.21
Block user comment: N
Private report: N
New Comment:
I think that this is a duplicate of bug #63740.
https://bugs.php.net/bug.php?id=63740
Previous Comments:
[2013-02-09 23:50:11] grey2k at gmail dot com
Description:
the problem is:
in sunday code output date for Monday next week
$date = new DateTime();
$date->setTimezone(new DateTimeZone('Europe/Moscow'));
$date->setTimestamp(strtotime('Monday this week'));
echo $date->format("d.m.Y");
but in other days (except Sunday) its return correct value of Monday.
I ever set locale manualy , which has a monday - the first day of week, but PHP
"think" the Sunday is still firs day. is it bug ?? or i do some wrong ?
for check this you need to set you local time in any Sunday.
Test script:
---
$date = new DateTime();
$date->setTimezone(new DateTimeZone('Europe/Moscow'));
$date->setTimestamp(strtotime('Monday this week'));
echo $date->format("d.m.Y");
Expected result:
The value on this week Monday.
for example in Sunday of 10.02.2012 i expect to see 04.02.2012.
Actual result:
--
if i test this code at Sunday 10.02.2012 - actual result is 11.02.2012
- it's wrong because this is a next week
--
Edit this bug report at https://bugs.php.net/bug.php?id=64181&edit=1
Bug #62351 [Com]: UTF-8 chars fail to be printed out properly with zend.multibyte
Edit report at https://bugs.php.net/bug.php?id=62351&edit=1 ID: 62351 Comment by: alexander dot stehlik at gmail dot com Reported by:php at sebastianmendel dot de Summary:UTF-8 chars fail to be printed out properly with zend.multibyte Status: Open Type: Bug Package:Unicode Engine related Operating System: GNU/Linux PHP Version:5.4.4 Block user comment: N Private report: N New Comment: I'm not sure if this issue is related but here is the problem I have with declare(ENCODING = 'utf-8'): Tested PHP Versions: PHP 5.4.6-1ubuntu1.1 (cli) PHP 5.4.6-1ubuntu1.1 (cgi-fcgi) Put this in a file (test.php): Run php test.php > test.txt In text.txt you can find some unreadable characters. This always occurs if there are special chars in any COMMENTS in the PHP file. Previous Comments: [2012-12-05 09:46:06] bukin242 at yandex dot ru Please fix in the new versions of php [2012-06-18 15:18:20] php at sebastianmendel dot de Description: Enabling zend.multibyte and having declare(encoding = UTF-8) in UTF-8 encoded scripts does not print UTF-8 chars properly. Same script (still encoded as UTF-8) but with declare(encoding = ISO-8859-1) prints out UTF-8 chars correct. >/opt/phpfarm/inst/bin/php-5.4.4 -i | grep multi zend.multibyte => On => On >/opt/phpfarm/inst/bin/php-5.4.4 -i | grep UTF default_charset => UTF-8 => UTF-8 zend.script_encoding => UTF-8 => UTF-8 exif.encode_unicode => UTF-8 => UTF-8 iconv.input_encoding => UTF-8 => UTF-8 iconv.internal_encoding => UTF-8 => UTF-8 iconv.output_encoding => UTF-8 => UTF-8 LANG => de_DE.UTF-8 _SERVER["LANG"] => de_DE.UTF-8 Test script: --- Expected result: "aäaà "aäaà Actual result: -- "aa "aâaâ -- Edit this bug report at https://bugs.php.net/bug.php?id=62351&edit=1
Bug #64187 [Com]: CGI/FastCGI truncates input to modulo 4GB
Edit report at https://bugs.php.net/bug.php?id=64187&edit=1
ID: 64187
Comment by: nachms+php at gmail dot com
Reported by:nachms+php at gmail dot com
Summary:CGI/FastCGI truncates input to modulo 4GB
Status: Open
Type: Bug
Package:Streams related
Operating System: Linux
PHP Version:5.4.11
Block user comment: N
Private report: N
New Comment:
In cgi_main.c, in sapi_cgi_read_post() and sapi_fcgi_read_post(), I found if I
comment out the line: count_bytes = MIN(count_bytes, (uint)
SG(request_info).content_length - SG(read_post_bytes));
Then the bug is fixed.
I'm not sure why the amount of bytes going to be read is bounded to
read_post_bytes subtracted from the length. read() will only read the amount
that it can, and it doesn't matter if you asked for too much, it will return
what is available.
For FastCGI, I'm not familiar enough with fcgi_read() enough to know if the
lack of bounding causes a problem or not. However, mod_php5 as an example
doesn't bound it. And if bounding is needed, this code needs to make use of
long or unsigned long instead of int and unit.
Previous Comments:
[2013-02-11 02:37:29] nachms+php at gmail dot com
I think I found the bug in cgi_main.c:
static int sapi_cgi_read_post(char *buffer, uint count_bytes TSRMLS_DC)
{
uint read_bytes = 0;
int tmp_read_bytes;
count_bytes = MIN(count_bytes, (uint) SG(request_info).content_length -
SG(read_post_bytes));
while (read_bytes < count_bytes) {
tmp_read_bytes = read(STDIN_FILENO, buffer + read_bytes,
count_bytes - read_bytes);
if (tmp_read_bytes <= 0) {
break;
}
read_bytes += tmp_read_bytes;
}
return read_bytes;
}
It looks like content_length, a long, is being truncated to a uint. I'll look
into fixing this based on what mod_php5 does.
[2013-02-11 01:57:46] nachms+php at gmail dot com
Description:
I've tested sending huge amounts of data via PUT to PHP from 5.3.x through
5.4.x via CGI, FastCGI, and mod_php for Apache, all on AMD64.
In all my tests, mod_php with Apache seems to be fine. However via CGI or
FastCGI, PHP can only see the amount of data modulo 4294967296. Which seems to
indicate that somewhere an int instead of a long is used in the the CGI
processing code, but so far, I have been unable to find where exactly. All my
builds are 64-bit, so that's not the issue.
To elaborate, via mod_php, if I send via HTTP PUT 4296015872 bytes, then PHP
will see all of them. However, via CGI or FastCGI, PHP will only see 1048576
bytes.
Test script:
---
http://paste.nachsoftware.com/Nach/TXmPR8289646bbb54bf40ce295115111acde1eYP
//Test via CGI (with FastCGI sharing results)
http://paste.nachsoftware.com/Nach/MXNpV4ec2e499fc0941773aff51184e6e618d2lN
Expected result:
When tested with either of my C test programs, I expect to see 4296015872
listed as the amount read.
Actual result:
--
With mod_php in Apache, I see 4296015872 which is correct. But with
CGI/FastCGI, I see 1048576 as the amount read, which is 4296015872%4294967296,
which indicates, somewhere a long is being converted to an int within the
CGI/FastCGI code.
--
Edit this bug report at https://bugs.php.net/bug.php?id=64187&edit=1
Bug #64132 [Opn]: PDO/MySQL query fails when binding a float value with data type PDO::PARAM_INT
Edit report at https://bugs.php.net/bug.php?id=64132&edit=1
ID: 64132
User updated by:ipernet at gmail dot com
Reported by:ipernet at gmail dot com
Summary:PDO/MySQL query fails when binding a float value
with data type PDO::PARAM_INT
Status: Open
Type: Bug
Package:PDO related
Operating System: Slackware 13 x64
PHP Version:5.4.11
Block user comment: N
Private report: N
New Comment:
Important note:
This only happens if the set locale use a comma as decimal separator.
Please add "setlocale(LC_ALL, 'fr_FR');" at the beginning of the test code to
reproduce.
This is still an unexpected behavior.
Previous Comments:
[2013-02-02 15:14:14] ipernet at gmail dot com
Description:
PHP:
5.4.11
PDO Client API version:
mysqlnd 5.0.10 - 20111026 - $Id: b0b3b15c693b7f6aeb3aa66b646fee339f175e39 $
MySQL:
5.5.18-log
Using a PDO prepared statement to insert a new row, the query fails if a float
value is passed for a token and this token use PDO::PARAM_INT as data type.
Test script:
---
CREATE TABLE IF NOT EXISTS `test` (
`kms` int(10) unsigned NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
---
$query = $dbh->prepare('INSERT INTO test(kms) VALUES(:kms)');
$query->bindValue(':kms', 1.25, PDO::PARAM_INT);
$query->execute();
var_dump($query->errorInfo());
Expected result:
- "1" should be inserted in the table
- Query should execute properly and do not lead to a SQL parsing error.
Actual result:
--
array(3) {
[0] =>
string(5) "21S01"
[1] =>
int(1136)
[2] =>
string(47) "Column count doesn't match value count at row 1"
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=64132&edit=1
Bug #61780 [Opn->Fbk]: Inconsistent PCRE captures in match results
Edit report at https://bugs.php.net/bug.php?id=61780&edit=1
ID: 61780
Updated by: paj...@php.net
Reported by:danielklein at airpost dot net
Summary:Inconsistent PCRE captures in match results
-Status: Open
+Status: Feedback
Type: Bug
Package:PCRE related
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
Be sure that every testing environment uses the exact same version of PCRE. PHP
only uses it and does not affect by any mean the parsing.
Previous Comments:
[2013-02-11 08:56:33] michael at mbaas dot de
Here is a reproduceable example (PHP 5.3.20 and 5.3.21) where named captures do
not return matches at all! I've tested this pattern against the PCRE-
Implementation in another language and it worked...
[" . $QQ . "\']*)(?
P.*?)(?P=quote)\s*/" . $del1 . "~";
$match=array();
preg_match($preg,$string,$match);
echo "string = " . htmlspecialchars($string) . "preg=" .
htmlspecialchars($preg) . "match:";var_dump($match);echo"";
?>
[2012-04-20 00:54:39] danielklein at airpost dot net
Description:
Named and unnamed captures in both preg_match and preg_match_all (and probably
preg_replace and the other PCRE functions too but I haven't tested them all)
can capture the wrong number of parentheses if alternation or a zero-or-more
quantifier is used.
If the pattern '/(?b)|(?c)|(?d)/' is used to match 'c', both 'b' and
'c' will be set in the results array but 'd' won't be. 'b' should not be set
(even to an empty string) as it failed to match anything. However, if it was
trying to match '/(?b?)(?c)/' (note: optional 'b' AND mandatory 'c'), 'b'
_should_ be set to '' as it's allowed to match a zero-length string. If a match
gets tried but it fails and a capture later in the pattern works, the skipped
capture should never produce a key in the results array. It should be OK to
leave holes in the numbered sequence (e.g. match 0 and 2 but not 1).
Currently, you need to use PREG_OFFSET_CAPTURE and test to see if the key
exists, and if it does, test to see if the capture position is -1. If this bug
is fixed, capture positions will never be -1 as the key won't exist.
Alternatively, an additional flag could be added (e.g. PREG_KEEP_NONMATCHES) to
create keys for ALL captures whether used or not (so, in the first pattern
above, keys would be created for 'b', 'c' and 'd' in all cases, and if matching
the string 'c' the offsets for both 'b' and 'd' would be -1).
In summary, if the pattern '/(?b)|(?c)|(?d)/' is used to match 'c', by
default it should only ever create a key for 'c'. If desired, an additional
flag could be added so that it creates keys for all captures: 'b', 'c' and 'd'.
The current behaviour where it creates a key for 'b' and 'c' but not 'd' should
be considered a bug and fixed.
Test script:
---
print('');
$offset = 0;
while (preg_match('/(?:(?b)|(?c)|(?d))(?e)?/', 'cdec', $matches,
PREG_OFFSET_CAPTURE, $offset)) {
$offset = $matches[0][1] + strlen($matches[0][0]);
var_export($matches);
print("\n\n");
}
print("\n\n");
preg_match_all('/(?:(?b)|(?c)|(?d))(?e)?/', 'cdec', $matches,
PREG_OFFSET_CAPTURE | PREG_SET_ORDER);
var_export($matches);
print('');
Expected result:
array (
0 =>
array (
0 => 'c',
1 => 0,
),
'c' =>
array (
0 => 'c',
1 => 0,
),
2 =>
array (
0 => 'c',
1 => 0,
),
)
array (
0 =>
array (
0 => 'de',
1 => 1,
),
'd' =>
array (
0 => 'd',
1 => 1,
),
3 =>
array (
0 => 'd',
1 => 1,
),
'e' =>
array (
0 => 'e',
1 => 2,
),
4 =>
array (
0 => 'e',
1 => 2,
),
)
array (
0 =>
array (
0 => 'c',
1 => 3,
),
'c' =>
array (
0 => 'c',
1 => 3,
),
2 =>
array (
0 => 'c',
1 => 3,
),
)
array (
0 =>
array (
0 =>
array (
0 => 'c',
1 => 0,
),
'c' =>
array (
0 => 'c',
1 => 0,
),
2 =>
array (
0 => 'c',
1 => 0,
),
),
1 =>
array (
0 =>
array (
0 => 'de',
1 => 1,
),
'd' =>
array (
0 => 'd',
1 => 1,
),
3 =>
array (
0 => 'd',
1 => 1,
),
'e' =>
array (
0 => 'e',
1 => 2,
),
4 =>
array (
0 => 'e',
1 => 2,
),
),
2 =>
array (
0 =>
array (
0 => 'c',
1 => 3,
),
'c' =>
array (
0 => 'c',
1 => 3,
),
2 =>
array (
0 => 'c',
1 => 3,
),
),
)
Actual result:
--
array (
0 =>
array (
0 => 'c',
1 => 0,
),
'b' =>
array (
0 => '',
1 => -1,
),
1 =>
array (
0 =>
Bug #61780 [Com]: Inconsistent PCRE captures in match results
Edit report at https://bugs.php.net/bug.php?id=61780&edit=1
ID: 61780
Comment by: michael at mbaas dot de
Reported by:danielklein at airpost dot net
Summary:Inconsistent PCRE captures in match results
Status: Open
Type: Bug
Package:PCRE related
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
Here is a reproduceable example (PHP 5.3.20 and 5.3.21) where named captures do
not return matches at all! I've tested this pattern against the PCRE-
Implementation in another language and it worked...
[" . $QQ . "\']*)(?
P.*?)(?P=quote)\s*/" . $del1 . "~";
$match=array();
preg_match($preg,$string,$match);
echo "string = " . htmlspecialchars($string) . "preg=" .
htmlspecialchars($preg) . "match:";var_dump($match);echo"";
?>
Previous Comments:
[2012-04-20 00:54:39] danielklein at airpost dot net
Description:
Named and unnamed captures in both preg_match and preg_match_all (and probably
preg_replace and the other PCRE functions too but I haven't tested them all)
can capture the wrong number of parentheses if alternation or a zero-or-more
quantifier is used.
If the pattern '/(?b)|(?c)|(?d)/' is used to match 'c', both 'b' and
'c' will be set in the results array but 'd' won't be. 'b' should not be set
(even to an empty string) as it failed to match anything. However, if it was
trying to match '/(?b?)(?c)/' (note: optional 'b' AND mandatory 'c'), 'b'
_should_ be set to '' as it's allowed to match a zero-length string. If a match
gets tried but it fails and a capture later in the pattern works, the skipped
capture should never produce a key in the results array. It should be OK to
leave holes in the numbered sequence (e.g. match 0 and 2 but not 1).
Currently, you need to use PREG_OFFSET_CAPTURE and test to see if the key
exists, and if it does, test to see if the capture position is -1. If this bug
is fixed, capture positions will never be -1 as the key won't exist.
Alternatively, an additional flag could be added (e.g. PREG_KEEP_NONMATCHES) to
create keys for ALL captures whether used or not (so, in the first pattern
above, keys would be created for 'b', 'c' and 'd' in all cases, and if matching
the string 'c' the offsets for both 'b' and 'd' would be -1).
In summary, if the pattern '/(?b)|(?c)|(?d)/' is used to match 'c', by
default it should only ever create a key for 'c'. If desired, an additional
flag could be added so that it creates keys for all captures: 'b', 'c' and 'd'.
The current behaviour where it creates a key for 'b' and 'c' but not 'd' should
be considered a bug and fixed.
Test script:
---
print('');
$offset = 0;
while (preg_match('/(?:(?b)|(?c)|(?d))(?e)?/', 'cdec', $matches,
PREG_OFFSET_CAPTURE, $offset)) {
$offset = $matches[0][1] + strlen($matches[0][0]);
var_export($matches);
print("\n\n");
}
print("\n\n");
preg_match_all('/(?:(?b)|(?c)|(?d))(?e)?/', 'cdec', $matches,
PREG_OFFSET_CAPTURE | PREG_SET_ORDER);
var_export($matches);
print('');
Expected result:
array (
0 =>
array (
0 => 'c',
1 => 0,
),
'c' =>
array (
0 => 'c',
1 => 0,
),
2 =>
array (
0 => 'c',
1 => 0,
),
)
array (
0 =>
array (
0 => 'de',
1 => 1,
),
'd' =>
array (
0 => 'd',
1 => 1,
),
3 =>
array (
0 => 'd',
1 => 1,
),
'e' =>
array (
0 => 'e',
1 => 2,
),
4 =>
array (
0 => 'e',
1 => 2,
),
)
array (
0 =>
array (
0 => 'c',
1 => 3,
),
'c' =>
array (
0 => 'c',
1 => 3,
),
2 =>
array (
0 => 'c',
1 => 3,
),
)
array (
0 =>
array (
0 =>
array (
0 => 'c',
1 => 0,
),
'c' =>
array (
0 => 'c',
1 => 0,
),
2 =>
array (
0 => 'c',
1 => 0,
),
),
1 =>
array (
0 =>
array (
0 => 'de',
1 => 1,
),
'd' =>
array (
0 => 'd',
1 => 1,
),
3 =>
array (
0 => 'd',
1 => 1,
),
'e' =>
array (
0 => 'e',
1 => 2,
),
4 =>
array (
0 => 'e',
1 => 2,
),
),
2 =>
array (
0 =>
array (
0 => 'c',
1 => 3,
),
'c' =>
array (
0 => 'c',
1 => 3,
),
2 =>
array (
0 => 'c',
1 => 3,
),
),
)
Actual result:
--
array (
0 =>
array (
0 => 'c',
1 => 0,
),
'b' =>
array (
0 => '',
1 => -1,
),
1 =>
array (
0 => '',
1 => -1,
),
'c' =>
array (
0 => 'c',
1 => 0,
),
2 =>
array (
0 => 'c',
1 => 0,
),
)
array (
0 =>
array (
0 => 'de',
1 => 1,
),
'b' =>
array (
0 => '',
1 => -1,
),
1 =>
array (
0 => '',
1 => -1,
[PHP-BUG] Bug #64188 [NEW]: strtotime is 7 times slower for dates that end with Z instead of UTC
From: efbiaiinzinz at hotmail dot com
Operating system: Windows / Linux / All
PHP version: 5.4.11
Package: Performance problem
Bug Type: Bug
Bug description:strtotime is 7 times slower for dates that end with Z instead
of UTC
Description:
According to the date rules seen at http://en.wikipedia.org/wiki/ISO_8601 a
date
with ending Z should be considered UTC date.
UTC description also says that UTC date can be denoted with appending Z to
the
end: http://en.wikipedia.org/wiki/Coordinated_Universal_Time
PHP codebase does follow those rules, but does so suboptimally.
We have a codebase that parses in big GPS files from different sport
watches and
so far all bigger providers (garmin, polar, suunto) encode the time values
in
those files as 2013-01-01T12:00:00Z or 2013-01-01T12:00:00.000Z.
We noticed that for bigger files the parsing times were quite bad and most
time
was spent in strtotime so we started to experiment. Removing the Z part
resulted
in fast strtotime but wrong result (date was assumed to be local not UTC).
When
we tried to replace Z with UTC, parsing was correct and fast.
After looking at date parsing code in PHP 5.4.11 we noticed few things:
ext/date/lib/parse_date.c
const static timelib_tz_lookup_table* zone_search(const char *word, long
gmtoffset, int isdst)
...
if (strcasecmp("utc", word) == 0 || strcasecmp("gmt", word) == 0) {
return timelib_timezone_utc;
}
ext/date/lib/parse_date.c
static long timelib_get_zone(char **ptr, int *dst, timelib_time *t, int
*tz_not_found, const timelib_tzdb *tzdb, timelib_tz_get_wrapper
tz_wrapper)
...
/* If we have a TimeZone identifier to start with, use it */
if (strstr(tz_abbr, "/") || strcmp(tz_abbr, "UTC") == 0) {
ext/date/lib/parse_date.c
const static timelib_tz_lookup_table timelib_timezone_utc[] = {
{ "utc", 0, 0, "UTC" },
};
There are optimizations for cases when string contains UTC but no
optimizations
for another official UTC format that ends with Z.
We tested on PHP 5.4.11 and 5.3.21 on a windows machin plus on our
production
Linux server with PHP 5.3.20.
Test script:
---
\r\n" : "\r\n";
$times_z = $times_utc = array();
$time = time();
$counter = 5;
for($i = 0; $i < $counter; $i++, $time++) {//Generate two arrays, one has
datetimes that end with Z and other has UTC endings
$date = date('Y-m-d\TH:i:s', $time);
$times_z []= $date . 'Z';
$times_utc []= $date . 'UTC';
}
for($start_z = microtime(true), $i = 0; $i < $counter; $i++) $tmp =
strtotime($times_z[$i]);
$dur_z = microtime(true) - $start_z;
for($start_u = microtime(true), $i = 0; $i < $counter; $i++) $tmp =
strtotime($times_utc[$i]);
$dur_u = microtime(true) - $start_u;
for($start_u2 = microtime(true), $i = 0; $i < $counter; $i++) $tmp =
strtotime(str_replace('Z', 'UTC', $times_utc[$i]));
$dur_u2 = microtime(true) - $start_u2;
echo 'Z took ' . number_format($dur_z, 4) . 's, UTC took ' .
number_format($dur_u, 4) . 's, Z with str_replace to UTC took ' .
number_format($dur_u2, 4) . 's' . $br;
if ($dur_z <= $dur_u) echo 'UTC format was ' . (number_format($dur_u /
$dur_z, 2)) . ' times slower than Z' . $br;
else echo 'Z format was ' . (number_format($dur_z / $dur_u, 2)) . ' times
slower than UTC' . $br;
Expected result:
I would expect to see UTC and Z versions having similar parsing times.
Actual result:
--
On windows with PHP 5.4.11, Z format parsing is 7 times slower than UTC
version,
using str_replace for all dates (Z => UTC) is 1.1 times slower than UTC
version.
On windows with PHP 5.3.21, Z format parsing is 6.1 times slower than UTC
version,
using str_replace for all dates (Z => UTC) is 1.1 times slower than UTC
version.
On Linux server with PHP 5.3.20 + APC, Z format parsing is 5 times slower
than UTC
version, using str_replace for all dates (Z => UTC) is 1.15 times slower
than UTC
version.
--
Edit bug report at https://bugs.php.net/bug.php?id=64188&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64188&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64188&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64188&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64188&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64188&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64188&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64188&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64188&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64188&r=support
Expected behavior: https://bugs.php.net/fix.php?id=64188&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64188&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64188&r=subm
Bug #64142 [Asn->Csd]: dval to lval different behavior on ppc64
Edit report at https://bugs.php.net/bug.php?id=64142&edit=1
ID: 64142
Updated by: r...@php.net
Reported by:r...@php.net
Summary:dval to lval different behavior on ppc64
-Status: Assigned
+Status: Closed
Type: Bug
Package:*General Issues
Operating System: GNU/Linux
PHP Version:5.4.11
Assigned To:remi
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of remi
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=e67a2b9e471a7bc0b774b9056bb38745b7187969
Log: Fixed bug #64142 (dval to lval different behavior on ppc64)
Previous Comments:
[2013-02-05 14:58:35] r...@php.net
@cataphract see my latest message on php-cvs ML.
Really strange. C Test (with -O2) give the same result on x86_64 and ppc64 and
seems to prove the fix is not needed.
No I need to understand why it improves the PHP result.
I can keep the test builder for some time, so will investigate on this...
[2013-02-05 12:37:07] cataphr...@php.net
BTW, that's with optimization turned off. If I pass -O3 to gcc , it's still
able to figure out it doesn't need to cast anything and the output is
-9223372036854775808.
In any case, we should get to the bottom of this. I very much doubt the patch
is wrong, but if we figure out the underling cause we may find out the problem
is larger.
[2013-02-05 12:32:35] cataphr...@php.net
> (long)(double)9223372036854775807-1 = 9223372036854775807
Ah sorry, I read that wrong. It can't obviously be rounding down, because the
result seems larger; you're subtracting one here when you're adding 1 on top...
The part about the closes doubles is wrong too, they're already spaced by 1024
by then.
In any case, your explanation in the commit seems both irrelevant and wrong. AS
to the wrong part, in x86_64:
printf("%ld\n",((long)(double)9223372036854775807)+1);
double dd = 9223372036854775807;
printf("%ld\n", ((long)dd) + 1);
gives
-9223372036854775808
-9223372036854775807
So the -9223372036854775808 result is just an artifact of the compiler doing
away with the casts completely.
[2013-02-05 11:05:02] cataphr...@php.net
The commit message says:
> On x86_64:
> (long)(double)9223372036854775807+1 = -9223372036854775808
> On ppc64
> (long)(double)9223372036854775807-1 = 9223372036854775807
How much is (long)(double)0x7fffL in that arch? Is it
0x7ffeL ?
The closest doubles near 0x7fff are 0x8000 and
0x7ffe. So basically ppp64 rounds down while x64 rounds up? If
that's the case, there's nothing to "fix" in the code; you'll presumably get
this behavior in a lot of other places, not just when casting LONG_MAX to
double.
But in any case, I don't see how that is relevant to the patch. The patch
changes a (long)dval cast to (long)(unsigned long)dval cast, which is a
double-to-long cast, not a long-to-double cast.
[2013-02-05 07:19:18] r...@php.net
Automatic comment on behalf of remi
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=6533094d9e4d0c85044a170d9fad9a3986a68675
Log: Fixed bug #64142 (dval to lval different behavior on ppc64)
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=64142
--
Edit this bug report at https://bugs.php.net/bug.php?id=64142&edit=1
