This is the mail archive of the
mailing list for the newlib project.
Re: How to implement qsort_r
- From: Yaakov Selkowitz <yselkowi at redhat dot com>
- To: newlib at sourceware dot org
- Date: Thu, 04 Dec 2014 11:20:59 -0600
- Subject: Re: How to implement qsort_r
- Authentication-results: sourceware.org; auth=none
- References: <547FCCB1 dot 1000201 at redhat dot com> <20141204092812 dot GB12194 at calimero dot vinschen dot de> <54807FB9 dot 3030202 at redhat dot com> <20141204162214 dot GB3320 at calimero dot vinschen dot de>
On 2014-12-04 10:22, Corinna Vinschen wrote:
On Dec 4 07:37, Eric Blake wrote:
On 12/04/2014 01:28 AM, Corinna Vinschen wrote:
The implementation is pretty simple either way, so, yes, we could
implement both and let the header provide both as well along the lines
Alternatively, are there any known efforts to standarize the API?
Eric, any word from the Austin group in terms of qsort_r?
No one has asked about it before; I can ask, but suspect that since
there is a difference in existing implementation, it would be easier for
POSIX to standardize a different function name than qsort_r than to pick
sides on which signature to standardize.
My personal preference is the glibc style (the opaque argument last in
both qsort_r and the comparator), not the BSD style (the opaque argument
first in both calls), This is because POSIX already has other
standardized functions in the glibc style (pthread_cleanup_push,
pthread_create), and none in the BSD styloe.
Good point. It's easier to implement, too, with qsort simply being a
shim to qsort_r with a NULL opaque argument. The qsort comparison
function won't even notice the extra argument.
I'll be borrowing the FreeBSD implementation either way, so that doesn't
seem to be a factor. I'll proceed with the patch.
Associate Software Engineer, ARM
Red Hat, Inc.