[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Undefined qsort behavior
- To: email@example.com
- Subject: Re: Undefined qsort behavior
- From: Katie Lucas <firstname.lastname@example.org>
- Date: Thu, 5 Dec 2002 20:46:05 +0000
- Delivered-to: email@example.com
- Delivered-to: mailing list firstname.lastname@example.org
- Delivery-date: Thu, 05 Dec 2002 19:49:22 -0500
- In-reply-to: <3DEF8287.41A19@gbl.com.br>
- Mailing-list: contact email@example.com; run by ezmlm
- References: <20021124110121.GC2021@ypisco.com> <3DE0EE31.firstname.lastname@example.org> <3DE1733E.email@example.com> <3DE19C32.firstname.lastname@example.org> <20021125191244.GD27874@fysh.org> <3DE2B388.email@example.com> <20021129180109.GB26555@fysh.org> <3DEF8287.41A19@gbl.com.br>
- Reply-to: firstname.lastname@example.org
- User-agent: Mutt/1.3.28i
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".