#38000 [NEW]: preg_match fails if strlen >= 1630
From: dave at smartboy dot com
Operating system: Windows XP
PHP version: 5.1.4
PHP Bug Type: PCRE related
Bug description: preg_match fails if strlen >= 1630
Description:
preg_match() with regexp to test for valid UTF-8 sequence - fails and
causes the error message:
'Could not open input file: .php'
IF the subject string passed to preg_match() is longer than 1629
characters. (Or in this case the size of the file 'zzz' which contains
ASCII)
There was no such limitation in preg_match() in the previous version of
PHP (5.1.2)
Reproduce code:
---
$str = file_get_contents('zzz');
echo "Loaded file...\n";
$result =
preg_match('/^([\x00-\x7f]|[\xc2-\xdf][\x80-\xbf]|\xe0[\xa0-\xbf][\x80-\xbf]|'
.
'[\xe1-\xec][\x80-\xbf]{2}|\xed[\x80-\x9f][\x80-\xbf]|[\xee-\xef][\x80-\xbf]{2}|'
.
'\xf0[\x90-\xbf][\x80-\xbf]{2}|[\xf1-\xf3][\x80-\xbf]{3}|\xf4[\x80-\x8f][\x80-\xbf]{2})*$/S',
$str) === 1;
echo "Back from preg_match()\n";
var_export($result);
echo "\n";
Expected result:
Loaded file...
Back from preg_match()
true
Actual result:
--
Loaded file...
Could not open input file: u8.php
--
Edit bug report at http://bugs.php.net/?id=38000&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38000&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38000&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38000&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38000&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38000&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38000&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38000&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38000&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38000&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38000&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38000&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38000&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38000&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38000&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38000&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38000&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38000&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38000&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38000&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38000&r=mysqlcfg
#38000 [Fbk->Opn]: preg_match fails if strlen >= 1630
ID: 38000
User updated by: dave at smartboy dot com
Reported By: dave at smartboy dot com
-Status: Feedback
+Status: Open
Bug Type: PCRE related
Operating System: Windows XP
PHP Version: 5.1.4
New Comment:
It turns out that no test file is needed
$str = str_repeat('a', 1575); //works
$str = str_repeat('a', 1576); //fails
There are really two issues:
- PCRE not working for "long" strings (although 1576 bytes is not
really a "long" string). This greatly limits the usefulness of regexp
pattern matching.
- When PCRE fails the error message is VERY misleading. Surely an
E_NOTICE should be issued by preg_match() if match has failed due to
out of memory, etc.? "Could not open input file" is just plain wrong.
Previous Comments:
[2006-07-04 14:40:01] [EMAIL PROTECTED]
please provide the zzz file. (either post a link to it or send it to my
e-mail).
----------------
[2006-07-04 00:46:02] dave at smartboy dot com
Description:
preg_match() with regexp to test for valid UTF-8 sequence - fails and
causes the error message:
'Could not open input file: .php'
IF the subject string passed to preg_match() is longer than 1629
characters. (Or in this case the size of the file 'zzz' which contains
ASCII)
There was no such limitation in preg_match() in the previous version of
PHP (5.1.2)
Reproduce code:
---
$str = file_get_contents('zzz');
echo "Loaded file...\n";
$result =
preg_match('/^([\x00-\x7f]|[\xc2-\xdf][\x80-\xbf]|\xe0[\xa0-\xbf][\x80-\xbf]|'
.
'[\xe1-\xec][\x80-\xbf]{2}|\xed[\x80-\x9f][\x80-\xbf]|[\xee-\xef][\x80-\xbf]{2}|'
.
'\xf0[\x90-\xbf][\x80-\xbf]{2}|[\xf1-\xf3][\x80-\xbf]{3}|\xf4[\x80-\x8f][\x80-\xbf]{2})*$/S',
$str) === 1;
echo "Back from preg_match()\n";
var_export($result);
echo "\n";
Expected result:
Loaded file...
Back from preg_match()
true
Actual result:
--
Loaded file...
Could not open input file: u8.php
--
Edit this bug report at http://bugs.php.net/?id=38000&edit=1
#38000 [Opn]: preg_match fails if strlen >= 1630
ID: 38000
User updated by: dave at smartboy dot com
Reported By: dave at smartboy dot com
Status: Open
Bug Type: PCRE related
Operating System: Windows XP
PHP Version: 5.1.4
New Comment:
$str = str_repeat('a', 100); //works in PHP 5.1.2
Previous Comments:
[2006-07-04 21:23:49] dave at smartboy dot com
It turns out that no test file is needed
$str = str_repeat('a', 1575); //works
$str = str_repeat('a', 1576); //fails
There are really two issues:
- PCRE not working for "long" strings (although 1576 bytes is not
really a "long" string). This greatly limits the usefulness of regexp
pattern matching.
- When PCRE fails the error message is VERY misleading. Surely an
E_NOTICE should be issued by preg_match() if match has failed due to
out of memory, etc.? "Could not open input file" is just plain wrong.
[2006-07-04 14:40:01] [EMAIL PROTECTED]
please provide the zzz file. (either post a link to it or send it to my
e-mail).
------------
[2006-07-04 00:46:02] dave at smartboy dot com
Description:
preg_match() with regexp to test for valid UTF-8 sequence - fails and
causes the error message:
'Could not open input file: .php'
IF the subject string passed to preg_match() is longer than 1629
characters. (Or in this case the size of the file 'zzz' which contains
ASCII)
There was no such limitation in preg_match() in the previous version of
PHP (5.1.2)
Reproduce code:
---
$str = file_get_contents('zzz');
echo "Loaded file...\n";
$result =
preg_match('/^([\x00-\x7f]|[\xc2-\xdf][\x80-\xbf]|\xe0[\xa0-\xbf][\x80-\xbf]|'
.
'[\xe1-\xec][\x80-\xbf]{2}|\xed[\x80-\x9f][\x80-\xbf]|[\xee-\xef][\x80-\xbf]{2}|'
.
'\xf0[\x90-\xbf][\x80-\xbf]{2}|[\xf1-\xf3][\x80-\xbf]{3}|\xf4[\x80-\x8f][\x80-\xbf]{2})*$/S',
$str) === 1;
echo "Back from preg_match()\n";
var_export($result);
echo "\n";
Expected result:
Loaded file...
Back from preg_match()
true
Actual result:
--
Loaded file...
Could not open input file: u8.php
--
Edit this bug report at http://bugs.php.net/?id=38000&edit=1
#38154 [NEW]: PHP CLI filemtime() is wrong
From: dave at smartboy dot com Operating system: Windows XP PHP version: 5.1.4 PHP Bug Type: Filesystem function related Bug description: PHP CLI filemtime() is wrong Description: Using PHP CLI on Windows - filemtime() returns an incorrect value. This problem does NOT occur with the Apache 2 SAPI. Value reported is ahead by 9 hours (could be time zone related? I am in GMT+10:00 time zone) Sample output: $ php test_filemtime.php 2006-07-20 18:20:08 $ ls -l test_filemtime.php -rw-r--r-- 1 Dave None 81 Jul 20 09:20 test_filemtime.php (the above from Cygwin) When running the exact same script inside Apache2 the correct time is printed 2006-07-20 09:20:08 Reproduce code: --- http://bugs.php.net/?id=38154&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38154&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38154&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38154&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38154&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38154&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38154&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38154&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38154&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38154&r=support Expected behavior:http://bugs.php.net/fix.php?id=38154&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38154&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38154&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38154&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38154&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38154&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38154&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38154&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38154&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38154&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38154&r=mysqlcfg
#38154 [Bgs->Opn]: PHP CLI filemtime() is wrong
ID: 38154 User updated by: dave at smartboy dot com Reported By: dave at smartboy dot com -Status: Bogus +Status: Open Bug Type: Filesystem function related Operating System: Windows XP PHP Version: 5.1.4 New Comment: Setting date.timezone does not change the behaviour. Changing the sample script to: http://bugs.php.net/?id=38154&edit=1
#38154 [Fbk->Opn]: PHP CLI filemtime() is wrong
ID: 38154 User updated by: dave at smartboy dot com Reported By: dave at smartboy dot com -Status: Feedback +Status: Open Bug Type: Filesystem function related Operating System: Windows XP PHP Version: 5.1.4 New Comment: Changed test_filemtime.php to: http://bugs.php.net/?id=38154&edit=1
[PHP-BUG] Bug #63449 [NEW]: SplObjectStorage should work more like a real array()
From: dave at smartboy dot com
Operating system: Linux
PHP version: 5.4.8
Package: SPL related
Bug Type: Bug
Bug description:SplObjectStorage should work more like a real array()
Description:
Attempting to use instances of class SplObjectStorage as an array results
in
exceptions and generally does not work as expected.
Test script:
---
$s = new SplObjectStorage;
$o = new stdClass;
$s[$o]["key"] = "value";
var_export($s[$o]);
// Fatal error: Uncaught exception 'UnexpectedValueException' with message
'Object not found'
Expected result:
The above sample code should create an array for the object key inside
SplObjectStorage, and display:
array (
'key' => 'value',
)
Compare the above code with:
$s = array();
$o = "someKey";
$s[$o]["key"] = "value";
var_export($s[$o]);
which works as expected and displays
array (
'key' => 'value',
)
Actual result:
--
Fatal error: Uncaught exception 'UnexpectedValueException' with message
'Object
not found' in Command line code:1
Stack trace:
#0 Command line code(1): SplObjectStorage->offsetGet(Object(stdClass))
#1 {main}
thrown in Command line code on line 1
--
Edit bug report at https://bugs.php.net/bug.php?id=63449&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63449&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63449&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63449&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63449&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63449&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63449&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63449&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63449&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63449&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63449&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63449&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63449&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63449&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63449&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63449&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63449&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63449&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63449&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63449&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63449&r=mysqlcfg
