[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Undefined qsort behavior
- To: firstname.lastname@example.org
- Subject: Re: Undefined qsort behavior
- From: Steve Baker <email@example.com>
- Date: Thu, 05 Dec 2002 16:30:17 -0600
- Delivered-to: firstname.lastname@example.org
- Delivered-to: mailing list email@example.com
- Delivery-date: Thu, 05 Dec 2002 19:58:14 -0500
- Mailing-list: contact firstname.lastname@example.org; run by ezmlm
- References: <20021124110121.GC2021@ypisco.com> <3DE0EE31.email@example.com> <3DE1733E.firstname.lastname@example.org> <3DE19C32.email@example.com> <20021125191244.GD27874@fysh.org> <3DE2B388.firstname.lastname@example.org> <20021129180109.GB26555@fysh.org> <3DEF8287.41A19@gbl.com.br> <20021205204605.GA31724@fysh.org>
- Reply-to: email@example.com
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204
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
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".
In this context, it most definitely means:
The order of two or more elements for which the 'compar' function
returns zero - are undefined RELATIVE TO EACH OTHER.
...and not "completely undefined".
The man page may be poorly worded - but any system whose qsort does not
return a sorted result (eg 1 3 2 2 instead of 1 2 2 3) would result in a
non-functioning machine in pretty short order.
I can't think of any case where I've seen Qsort being used where the
author of the comparison function took the time to ensure that it
never returns zero...which is what is implied by this concern. The
man page would be FAR more strongly worded if that were the case.
What this means is that if you have:
...you *MAY* get:
APPLES, ORANGES, LEMONS, BANANAS
...but at random, you might get....
APPLES, LEMONS, ORANGES, BANANAS
...but you'll NEVER get:
LEMONS, APPLES, ORANGES, BANANAS
...just because 'compar(LEMONS,ORANGES)==0'.
---------------------------- Steve Baker -------------------------
HomeEmail: <firstname.lastname@example.org> WorkEmail: <email@example.com>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net http://tuxaqfh.sf.net