Re: lib/43488 (rb.[hc] API critiques/problems that should be addressed before final release)

[Jeremy Huddleston <jeremyhu%apple.com@localhost>]

The following reply was made to PR lib/43488; it has been noted by GNATS.

From: Jeremy Huddleston <jeremyhu%apple.com@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: agc%NetBSD.org@localhost, lib-bug-people%netbsd.org@localhost, 
netbsd-bugs%netbsd.org@localhost,
 gnats-admin%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) 
says:
 
      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
 > Responsible-Changed-Why:
 > 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
 > State-Changed-Why:
 > 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.
 > 
 > 
 >