> I was just providing evidence to the original poster's claim that qsort *can* produce
> different results because it's inherently not a stable sort algorithm.
>
> In practice, due to the way that MAME uses qsort, I don't know if it actually *does*
> produce different output. Re-reading the original post, I'm not sure that he's even
> claiming that it actually *is* producing different output.
Yes, the output is different. Even the same chdman binary produces a different output when run 1) under Wine, using Wine's C library, and 2) under real Windows, using msvcrt.dll.
> I guess we need for him to come back and provide some proof.
With the patch I attached, it's possible to eg. reverse the order of the secondary sort key, which yields completely different (but also valid) compressed data. So the exact qsort() implementation really matters.
Yet another minor issue:
I also noticed that one byte near the end of the output chaosheatj.chd can have several different values. Valgrind reports usage of some uninitialized bytes when writing the index, I'll look into that later.
|
Index 
Flat 
Re: bug: chdman output depends on system qsort() implementation
Reply
Re: bug: chdman output depends on system qsort() implementation
