Re: [PHP4BETA] rsort() bug?
| From: | Alfred Perlstein | Date: | Wed, 10 May 2000 21:56:39 +0000 |
| Subject: | Re: [PHP4BETA] rsort() bug? | ||
| References: | 1 2 3 | Groups: | php.version4 |
| Request: | Send a blank email to php-version4+get-14792@lists.php.net to get a copy of this message | ||
* Andrei Zmievski <andrei@ispi.net> [000510 14:35] wrote:
> On Wed, 10 May 2000, Sascha Schumann wrote:
> > Solaris' qsort does not like that. We cannot change
> > compare_function, because that would break thousands of scripts.
> > rsort() should not use qsort.
>
> Then we have a problem. I changed rsort() to use mergesort() and ran
> this example through it.
>
> <?
> $ar1 = array("100", 10, "10", "9", "abc");
> rsort($ar1);
> ?>
>
> The results were:
>
> array(5) {
> [0]=>
> string(3) "100"
> [1]=>
> int(10)
> [2]=>
> string(3) "abc"
> [3]=>
> string(2) "10"
> [4]=>
> string(1) "9"
> }
>
> Which is clearly not correct.
>
> We seem to be between a rock and a hard place - qsort() crashes and
> mergesort() doesn't produce valid results. All because
> compare_function() is non-deterministic.
Just roll/import your own version of qsort that is ok with a
non-deterministic comparison function, they exist no?
I think FreeBSD's is ok with it.
Another option that could be investigated is using thread private
data to maintain a global that describes what the array is composed
of, then your comparison function can operate as expected.
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."