Re: Undefined qsort behavior

["Miguel A. Osorio" <maos@gbl.com.br>]

Katie Lucas wrote:
> 
> On Thu, Dec 05, 2002 at 02:44:55PM -0200, Miguel A. Osorio wrote:
> 
> > material/texture). But the qsort man page says: "If  two  members
> > compare as equal, their order in the sorted array is undefined". So my
> > question is this: this "undefined order" still groups equal elements
> > together, or is the undefined *really* undefined ? For instance, if I
> > have an array: 4 2 3 1 2 4, do I *always* get: 1 2 2 3 4 4 ?
> 
> "Undefined" has a very technical defintion. It means, very literally,
> the behaviour has not been specified in ANY WAY and the routine is
> free to do as it pleases with it.
> 
> It could vary between library implementations, between machines with
> different CPUs, it could vary on initial conditions, sizes of the
> arrays; absolutely ANYTHING. And when it does so, you have no
> comeback.
> 
> Testing it on your machine and using that undefined bahaviour is
> asking for it not to work somewhere else later. You might as well
> raise the bug against that bit of code yourself.
> 
> Undefined means "don't use this, it might stop working like it does at
> any point in time".

	Hum, I see. I did think in those terms, but then again, what about the
quicksort algorithm? I mean, does this undefined behavior come from the
algorithm, or specifically from the standard C lib implementation? If
the problem is the library, I could always write a qsort myself, with a
defined behavior for equal elements, but if the problem is the
algorithm, then it's no quicksort for me :)



Thank you for your attention,
Miguel A. Osorio