Alexander Monakov <amona...@ispras.ru> writes:
> I'm not sure. It has a weaker contract compared to qsort, and I believe
> functions in libiberty are understood to provide stronger/better replacements.
The original intent of libiberty was to provide a stronger *portability*
contract, i.e. to work around differences in underlying operating
systems. The xfoo() variants often handle error conditions also, as
that has traditionally been something that OSs do differently anyway.
Having said that, adding something to libiberty is more complicated than
adding something to gcc (it didn't used to be), and if nobody else needs
a more portable qsort, it's a wasted effort.
Libiberty is *not* a generic "toss things in here because they're useful
and generic" library, despite being used as such. However, it is common
among a few large projects (which used to share a repo, limiting copies
of libiberty to one), and does help in code re-use.
Given all that, I'd say that an xqsort might be appropriate in
libiberty, if it was (1) able to take over for the generic qsort[1] ,
and (2) the changes are also needed or useful in one of the other
projects using libiberty. But given that it's currently written in C++
(it would need to be C-compatible) and only used by gcc, IMHO putting it
in libiberty would be inappropriate at this time. The fact that qsort
is defined to be nondeterministic is not a portability issue[2].
Consider that there is also gnulib, which serves a similar purpose.
[1] i.e. if replacing qsort() with xqsort() in a C or C++ program
resulted in the same behavior as far as standards imply.
[2] if the nondeterminism is a problem, you probably need to fix your
compare function ;-)
