#49698 [NEW]: Unexpected change in strnatcasecmp()
From: sander dot vink at procurios dot nl Operating system: Linux PHP version: 5.2.11 PHP Bug Type: Strings related Bug description: Unexpected change in strnatcasecmp() Description: We use the strnatcasecmp()-function to get a natural order in our lists of items. Up until PHP 5.2.9 it worked like a charm, but since we upgraded to PHP 5.2.11 the order seems to have been changed. The natural order is used in our case to support the sorting of items that have been prefixed with numbers (0, 1, 2, etc). This is exactly where the problem arises: 0 should be sorted before 1, but this is no longer the case. This problem also occurs in the latest snapshot of PHP 5.3 Reproduce code: --- ?php $string1 = '0 Foo'; $string2 = '1 Bar'; var_dump(strnatcasecmp($string1, $string2)); Expected result: int(-1) Actual result: -- int(1) -- Edit bug report at http://bugs.php.net/?id=49698edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49698r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49698r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49698r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49698r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49698r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49698r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49698r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49698r=needscript Try newer version: http://bugs.php.net/fix.php?id=49698r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49698r=support Expected behavior: http://bugs.php.net/fix.php?id=49698r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49698r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49698r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49698r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49698r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49698r=dst IIS Stability: http://bugs.php.net/fix.php?id=49698r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49698r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49698r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49698r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49698r=mysqlcfg
#49698 [Com]: Unexpected change in strnatcasecmp()
ID: 49698 Comment by: sander dot vink at procurios dot nl Reported By: sander dot vink at procurios dot nl Status: Open Bug Type: Strings related Operating System: Linux PHP Version: 5.2.11 New Comment: I have tried the latest snapshot again (Built on: Sep 28, 2009 10:30 UTC) and the expected result is still not acquired. Are you sure it is fixed in PHP 5.3-HEAD, and if so, when will it be available as either snapshot or release? Previous Comments: [2009-09-28 11:22:53] sjo...@php.net This seems to be solved already in PHP 5.3-HEAD. [2009-09-28 07:56:04] sander dot vink at procurios dot nl Description: We use the strnatcasecmp()-function to get a natural order in our lists of items. Up until PHP 5.2.9 it worked like a charm, but since we upgraded to PHP 5.2.11 the order seems to have been changed. The natural order is used in our case to support the sorting of items that have been prefixed with numbers (0, 1, 2, etc). This is exactly where the problem arises: 0 should be sorted before 1, but this is no longer the case. This problem also occurs in the latest snapshot of PHP 5.3 Reproduce code: --- ?php $string1 = '0 Foo'; $string2 = '1 Bar'; var_dump(strnatcasecmp($string1, $string2)); Expected result: int(-1) Actual result: -- int(1) -- Edit this bug report at http://bugs.php.net/?id=49698edit=1
#49698 [Com]: Unexpected change in strnatcasecmp()
ID: 49698 Comment by: sander dot vink at procurios dot nl Reported By: sander dot vink at procurios dot nl Status: Open Bug Type: Strings related Operating System: Linux PHP Version: 5.2.11 New Comment: To be a little more specific, I used the latest snapshot of PHP 5.3 (shown as PHP 5.3.2-dev). Previous Comments: [2009-09-28 11:49:09] sander dot vink at procurios dot nl I have tried the latest snapshot again (Built on: Sep 28, 2009 10:30 UTC) and the expected result is still not acquired. Are you sure it is fixed in PHP 5.3-HEAD, and if so, when will it be available as either snapshot or release? [2009-09-28 11:22:53] sjo...@php.net This seems to be solved already in PHP 5.3-HEAD. [2009-09-28 07:56:04] sander dot vink at procurios dot nl Description: We use the strnatcasecmp()-function to get a natural order in our lists of items. Up until PHP 5.2.9 it worked like a charm, but since we upgraded to PHP 5.2.11 the order seems to have been changed. The natural order is used in our case to support the sorting of items that have been prefixed with numbers (0, 1, 2, etc). This is exactly where the problem arises: 0 should be sorted before 1, but this is no longer the case. This problem also occurs in the latest snapshot of PHP 5.3 Reproduce code: --- ?php $string1 = '0 Foo'; $string2 = '1 Bar'; var_dump(strnatcasecmp($string1, $string2)); Expected result: int(-1) Actual result: -- int(1) -- Edit this bug report at http://bugs.php.net/?id=49698edit=1
#47838 [Com]: For some strict notices __autoload isn't used in the error handler
ID: 47838
Comment by: sander dot vink at procurios dot nl
Reported By: taco at procurios dot nl
Status: Open
Bug Type: Unknown/Other Function
Operating System: Ubuntu
PHP Version: 5.2.9
New Comment:
The same error occurs on the latest snapshot of PHP5.3 (Built on: Mar
30, 2009 12:30 UTC):
Actual result:
--
My Error: Declaration of Baz::bar() should be compatible with that of
Foo::bar()
Fatal error: Class 'Qux' not found in
/Users/svink/Desktop/bugtest/php_bug1_2.php on line 15
Previous Comments:
[2009-03-30 12:55:40] taco at procurios dot nl
Description:
We dynamicly load a logging class in our error handler function using
autoload. For some STRICT notices (Declaration of Baz::bar() should be
compatible with that of Foo::bar()) the __autoload() function isn't
called to load that logging class.
If you replace the line require('php_bug1_2.php'); with mktime();,
which also casts an E_STRICT notice, you'll see the expected result
instead of the missing Qux class error.
Reproduce code:
---
http://thh.takkie.nl/php_bug1.php
Expected result:
My Error: Declaration of Baz::bar() should be compatible with that of
Foo::bar()
Stuff is done
Actual result:
--
My Error: Declaration of Baz::bar() should be compatible with that of
Foo::bar()
Fatal error: Class 'Qux' not found in
/data/www/thh.takkie.nl/public_html/php_bug1_2.php on line 15
--
Edit this bug report at http://bugs.php.net/?id=47838edit=1
#46614 [Fbk-Opn]: Extended MySQLi class gives incorrect empty() result
ID: 46614
User updated by: sander dot vink at procurios dot nl
Reported By: sander dot vink at procurios dot nl
-Status: Feedback
+Status: Open
Bug Type: MySQLi related
Operating System: Mac OS X 10.5.5
PHP Version: 5.3CVS-2008-11-19 (snap)
New Comment:
Yes, exactly, it is not empty. However, I return the result of empty()
( not !empty() ) which should be false, since the array actually
contains data.
Previous Comments:
[2008-11-19 23:12:58] [EMAIL PROTECTED]
You set $this-fooData[]to contain 'Bar' - it's not empty - returns
true..what's the bug..?
[2008-11-19 13:25:11] sander dot vink at procurios dot nl
Description:
When an empty() call is done within a class that extends the MySQLi
class, an incorrect result is provided.
Reproduce code:
---
class Foo extends MySQLi
{
protected $fooData = array();
public function isEmpty()
{
$this-fooData[] = 'Bar';
return empty($this-fooData);
}
}
$Foo = new Foo('localhost', 'root', '', 'test');
$isEmpty = $Foo-isEmpty();
var_dump($isEmpty);
Expected result:
bool(false)
Actual result:
--
bool(true)
--
Edit this bug report at http://bugs.php.net/?id=46614edit=1
#46614 [NEW]: Extended MySQLi class gives incorrect empty() result
From: sander dot vink at procurios dot nl
Operating system: Mac OS X 10.5.5
PHP version: 5.3CVS-2008-11-19 (snap)
PHP Bug Type: MySQLi related
Bug description: Extended MySQLi class gives incorrect empty() result
Description:
When an empty() call is done within a class that extends the MySQLi class,
an incorrect result is provided.
Reproduce code:
---
class Foo extends MySQLi
{
protected $fooData = array();
public function isEmpty()
{
$this-fooData[] = 'Bar';
return empty($this-fooData);
}
}
$Foo = new Foo('localhost', 'root', '', 'test');
$isEmpty = $Foo-isEmpty();
var_dump($isEmpty);
Expected result:
bool(false)
Actual result:
--
bool(true)
--
Edit bug report at http://bugs.php.net/?id=46614edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46614r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46614r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46614r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46614r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46614r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46614r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46614r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46614r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46614r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46614r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46614r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46614r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46614r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46614r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46614r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46614r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46614r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46614r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46614r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46614r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46614r=mysqlcfg
