Sorting Bug / Wrong behavior?

Notice how 0 and c are switched incorrectly. Attached is a patch to
zend_operators.c that fixes it.

The Manual says:

Warning

Be carefull when sorting arrays with mixed types values because sort()
can produce unpredictable results.

You could use SORT_STRING, natsort, etc...

If this gets "fixed", the $a = "0d9"; var_dump(++$a, ++$a); thing could
also be "fixed", as its WTF factor is as high... or "010" == "1e1" being
true. It's all the consequence of PHPs handling with numbers and
strings, which can produce results that strike you as odd.

This isn't a bug. All those strings evaluate to 0.
You should use a sort() function which is suitable.

At 02:48 PM 7/27/2004 -0500, John Coggeshall wrote:

Consider the following:

<?php $a = array('a', 'b', 'c', 'a'=>0, 'b'=>1, 'c'=>2);
sort($a);
print_r($a);
?>

This produces a bogus output:

Array
(
[0] => a
[1] => b
[2] => 0
[3] => c
[4] => 1
[5] => 2
)

Notice how 0 and c are switched incorrectly. Attached is a patch to
zend_operators.c that fixes it.

I talked to John about this yesterday. I'll take a closer look at this
within the coming days to see if this makes sense and how it affects BC in
general (if at all).

At 09:45 PM 7/27/2004 +0200, Marcus Boerger wrote:

Hello John,

Tuesday, July 27, 2004, 9:48:28 PM, you wrote:

Consider the following:

<?php $a = array('a', 'b', 'c', 'a'=>0, 'b'=>1, 'c'=>2);
sort($a);
print_r($a);
?>>

This produces a bogus output:

Array
(
[0] => a
[1] => b
[2] => 0
[3] => c
[4] => 1
[5] => 2
)

Notice how 0 and c are switched incorrectly. Attached is a patch to
zend_operators.c that fixes it.

The current order simply makes no sense at all.´The following though would:
0 a b c 1 2 // zero dirst, then strings then numbers
a b c 0 1 2 // strings first, then numbers
0 1 2 a b c // numbers first, then strings

and btw, john you forgot the patch, it is attached here.
The one provided does the 2nd which means we only ensured
0 is treated un the same way other numbers are.

Best regards,
Marcus mailto:helly@php.net

How would you expect the sort function to behave on the following:
array(true, false, 0, 1)?
It is a different way of looking at the same problem and you are likely to
hit this anytime you start comparing/sorting different data types.
In general, I don't think it makes very much sense to fix the comparison
operator for these special cases.
PHP has always done this kind of type juggling and you would be changing a
lot of its behavior.
I suggest that when you do try and sort an array with different kind of
data you define your own sorting callback function.
Making special cases for each such case in the compare function will not
only change behavior but it will slow down the already "too big for my
taste" compare function.
I know it's not the answer John was hoping for (I promised him to look into
it more deeply when I'm back from OSCON) but after doing so and thinking
about it, I think we'd be going in a direction which wouldn't be good.
I have a feeling this might also not give you the expected behavior for
something like array(0, "-1") but I haven't actually ran it.

Andi

At 09:45 PM 7/27/2004 +0200, Marcus Boerger wrote:

Hello John,

Tuesday, July 27, 2004, 9:48:28 PM, you wrote:

Consider the following:

<?php $a = array('a', 'b', 'c', 'a'=>0, 'b'=>1, 'c'=>2);
sort($a);
print_r($a);
?>>

This produces a bogus output:

Array
(
[0] => a
[1] => b
[2] => 0
[3] => c
[4] => 1
[5] => 2
)

Notice how 0 and c are switched incorrectly. Attached is a patch to
zend_operators.c that fixes it.

The current order simply makes no sense at all.´The following though would:
0 a b c 1 2 // zero dirst, then strings then numbers
a b c 0 1 2 // strings first, then numbers
0 1 2 a b c // numbers first, then strings

and btw, john you forgot the patch, it is attached here.
The one provided does the 2nd which means we only ensured
0 is treated un the same way other numbers are.

Best regards,
Marcus mailto:helly@php.net