[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: lib/43488 (rb.[hc] API critiques/problems that should be addressed before final release)
The following reply was made to PR lib/43488; it has been noted by GNATS.
From: Jeremy Huddleston <jeremyhu%apple.com@localhost>
Cc: agc%NetBSD.org@localhost, lib-bug-people%netbsd.org@localhost,
Subject: Re: lib/43488 (rb.[hc] API critiques/problems that should be addressed
before final release)
Date: Mon, 21 Jun 2010 11:19:16 -0700
Actually, the comparison functions are opposite what qsort does. qsort(3)
The comparison function must return an integer less than, equal to, or
greater than zero if the first argument is considered to be respectively
less than, equal to, or greater than the second.
That is consistent with strcmp(3) and is opposite what rb(3) states.
On Jun 19, 2010, at 16:24, agc%NetBSD.org@localhost wrote:
> Synopsis: rb.[hc] API critiques/problems that should be addressed before
> final release
> Responsible-Changed-From-To: lib-bug-people->agc
> Responsible-Changed-By: agc%NetBSD.org@localhost
> Responsible-Changed-When: Sat, 19 Jun 2010 23:24:14 +0000
> I thought I'd channel matt@ for this one
> State-Changed-From-To: open->analyzed
> State-Changed-By: agc%NetBSD.org@localhost
> State-Changed-When: Sat, 19 Jun 2010 23:24:14 +0000
> matt was saying that the comparator functions are modelled on the qsort ones,
> which seems to be the correct approach to this pair of eyes - most people
> cast within the comparison routine to the required type of argument, which
> adds an air of genericism to the sorting, at the cost of access through void
> * pointers.
> matt is also going to take a further look to check the direction of testing.
> I'll update the bug when the oracle speaks further.
Main Index |
Thread Index |