Ok, I'm getting somewhere now. This code breaks:
[_Image_XMP.pike] | if(sizeof(data) < ncolors+2) | error("Too few elements in array to decode color values\n"); | array colors; | if(cpp < 4) | colors = data[1..ncolors]; | else | colors = sort(data[1..ncolors]); | | // sort(colors); | // werror("cpp:%d\n",cpp);
If I add that extra sort, it sorts correctly and works. The werror reveals cpp to be 21 (not <4).
/ Mirar
Previous text:
2003-01-31 08:39: Subject: XPM and sort
Aahrg, my mind is breaking up here.
The code snippet that needs to run to get XPM to break is, *drumroll*,
test_do([[ mixed eat_stack() { mixed err = 1; if (catch (err = eat_stack()) || err != 10) return intp (err) && err ? err + 1 : err; if (err = catch { class Foo { object foo; static void create(object o) {foo = o;} }; Foo foo; for(int i=0; i < 10000; i++) foo = Foo(foo); gc(); }) return err; }; if (mixed err = eat_stack()) throw (err); ]])
I found it through manual binary search. Every other test is commented out with dnl. If I comment out this one, XPM works again.
I'm starting to suspect that there is something other then memcmp that is funny here... I can't seem to find any way of forcing sort to behave, so I consider sort() as totally ok (for now). But I'm slowly going insane now, so don't trust me.
/ Mirar