Reclassified.

On Digital UNIX V4.0G (Rev. 1530), sort() does not work with PHP 4.2.1, either. It does work with PHP 4.0.5 on that same platform. Should I try PHP 4.1.x to see where things started to go wrong?

This would be great. I tested it on PHP 4.2.1 on Win2k, it worked fine. So it seems to be a platform specific problem. 

I can help you with testing other versions on that machine/fixing the bug. It would be nice, if some of the core developers (maybe Andrei, Andi, Rasmus, Zeev, Jeroen, Derick - these are the people who did most changes in the last months on array.c) could give us some information on what files may affect this.

I've found that between 4.0.5 and 4.2.1 nearly the whole source for PHP_FUNCTION(sort) has changed.

Updated version according to Michaels tests.

I checked some older versions:
until PHP-4.1.2, sort() was fine. I didn't check 4.2.0RC*, yet, but will do so tomorrow.

Well,
the script runs fine under my IRIX64 6.5.16m on mod_php/Apache 1.3.24 but not when using a 64bit cgi binary with Apache2.

Case 1
http://sgi.takenet.de/php/sort.php

Case 2
http://sgi.takenet.de:8080/php/sort.php

Bug #17257 seems to be the same problem ("Digital UNIX OSF/1" is the old name of "Compaq Tru64"). People there found that all sort functions broke with PHP-4.2.0RC1, I can confirm this now.

Smallest test program:

<?php
$a = array(9,7,3,5);
sort($a);
print_r($a);
?>

Output:

Array
(
    [0] => 9
    [1] => 7
    [2] => 3
    [3] => 5
)

It's not compiler-related, both gcc-2.95.2 and Compac C V6.3-129 give the same results. Maybe endianess-related (the Compaq machine have Alpha processors)?

If somebody more clueful wants to take a look at this problem: Compaq provides free test accounts (not only with Tru64, but also with FreeBSD, NetBSD and Linux), see
<http://www.testdrive.compaq.com/>.

I compiled PHP-4.2.0RC1 there on FreeBSD/Alpha, and gcc-2.95.3 gives lots of warnings:

***	The -O2 flag TRIGGERS KNOWN OPTIMIZER BUGS ON THIS PLATFORM

But even with CFLAGS="-O0 -g" sort() does not sort at all.

On FreeBSD/Intel it does work, so it probably is an endianess problem.

4.2.0RC1 introduced the new sorting code Zend/zend_qsort.c from Sterling, maybe that's related?

This may be related to a casting problem which is supposed to be fixed in HEAD, please try this version (snapshots are available at snaps.php.net), thx.

php4-200205280000.tar.gz doesn't compile here:

% configure --prefix=/Team/local
[...]
gcc  -Imain/ -I/Team/local/src/php4-200205280000/main/ -DPHP_ATOM_INC -I/Team/local/src/php4-200205280000/include -I/Team/local/src/php4-200205280000/main -I/Team/local/src/php4-200205280000 -I/Team/local/src/php4-200205280000/Zend -I/Team/local/src/php4-200205280000/ext/xml/expat  -I/Team/local/src/php4-200205280000/TSRM -g -O2  -c /Team/local/src/php4-200205280000/main/user_streams.c -o main/user_streams.o  && echo > main/user_streams.lo
In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36,
                 from /Team/local/src/php4-200205280000/Zend/zend.h:59,
                 from /Team/local/src/php4-200205280000/main/php.h:34,
                 from /Team/local/src/php4-200205280000/main/user_streams.c:22:
/usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list'
/usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here
Make:  Don't know how to make /zend_language_parser.c.  Stop.

Zend/zend_language_parser.c exists, but the Makefile searches for /zend_language_parser.c and several other files in /.

Still does not sort with php4-STABLE-200206070600.

bash-2.01$ php   
<?php
$a = array(9,7,3,5);
sort($a);
print_r($a);
?>

X-Powered-By: PHP/4.2.2-dev
Content-type: text/html

Array
(
    [0] => 9
    [1] => 7
    [2] => 3
    [3] => 5
)

STABLE != HEAD, you have to try the non-STABLE snapshot.

Thanks, I didn't know that.

With php4-200206070600, sort() works again, so this bug is solved:

bash-2.01$ ./php 
Unaligned access pid=24680 <php> va=0x14005d27c pc=0x1201ad760 ra=0x1201ad754 inst=0xb4010000
<?php
$a = array(9,7,3,5);
sort($a);
print_r($a);
?>
X-Powered-By: PHP/4.3.0-dev
Content-type: text/html

Array
(
    [0] => 3
    [1] => 5
    [2] => 7
    [3] => 9
)

I had some problems compiling it on Tru64, though, and the "unaligned access" doesn't look especially pretty, too.
I will open a new bug report for these (if nobody else did).

Thank you for your help!

This bug still exists in the 4.2.3RC1 version on 
Compaq Tru64 (OSF1 xxxxxxx V5.1 1885 alpha):

My very simple test case:

$ar1 = array("k","i","f","o","p","b");
print "unsorted ar1:";
print_r($ar1);
reset($ar1);
sort($ar1);
print "sorted ar1";
print_r($ar1);

The results:

unsorted ar1:Array
(
    [0] => k
    [1] => i
    [2] => f
    [3] => o
    [4] => p
    [5] => b
)
sorted ar1Array
(
    [0] => k
    [1] => i
    [2] => f
    [3] => o
    [4] => p
    [5] => b
)

The configure options, taken from further
installation on this machine:

./configure  --with-mysql --with-xml --enable-ftp --with-pcre \
--with-gd=/usr/local --with-png-dir=/usr/local \
--with-zlib=/usr/local --with-freetype --with-sessions \
--enable-trans-sid --enable-memory-limit

Sorry, but I don't understand why this
bug is declared as "closed", although 
sorting doesn't work in this release candicate. :-(

Attention!

I replicated the problem with 4.2.2 on Tru64, but found that it was fixed by replacing Zend/zend_qsort.c with the latest from CVS, version 1.3 (HEAD)

I am not getting unaligned accesses.

I just merged the changes from HEAD to the 4.2.x branch.
Please test next RC when it comes out (tomorrow, propably)

Ok, I've tested the new php-4.2.3RC2 on 
Compaq Tru64 (details see above), and it
works.

Verified this as working on Compaq Tru64, but the behaviour of array_unique changed between 4.2.3RC1 and 4.2.3RC2, see http://marc.theaimsgroup.com/?t=103103891800003&r=1&w=4