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:11: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>
On 2014-12-04 09: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.
Generally I would agree, but wouldn't it make more sense to group
together the arguments to compar, IOW:
void qsort_r(void *base, size_t nmemb, size_t size, void *arg, int
(*compar)(const void *, const void *, void *));
Associate Software Engineer, ARM
Red Hat, Inc.