Huh? What is pike's "sort" here, and why would *any* operation on pike strings ever use strcmp rather than memcmp?
/ Niels Möller ()
Previous text:
2003-01-30 22:39: Subject: XPM and sort
I finally figured out why XPM decoding is broken on my system.
It uses sort() to sort the colors, but a binary comparison in a quicksearch algorithm. sort() uses strcmp. strcmp doesn't sort in binary order on my system¹.
I thought it had something to do with large INT_TYPE, but now I'm convinced so isn't the case. This is the order I get:
... "*Y c #eecc22", "*Z c #ffcc22", "=` c #00dd22", "=. c #11dd22", "=+ c #22dd22", "=@ c #33dd22", "=# c #44dd22", ...
Note the '`' before '.'.
The bug makes the XPM module not find most of the colors, and thus rendering an almost completely black image.
Could we make the Pike sort()'s strcmp compare binary? Or does anyone feel up to fixing the XPM module?
(¹ appearantly, my default locale is good enough - the bug only appears if the main testsuite is run before. )
/ Mirar