This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 6/6] qsort comparator consistency checking
On Thu, 3 Aug 2017, Jakub Jelinek wrote:
> Do we really need to rename and poison anything? qsort () in the source is
> something that is most obvious to developers, so trying to force them to use
> something different will just mean extra thing to learn.
Yep, I'd prefer to have a solution that keeps C-style qsort invocations as-is.
Note that with vec::qsort -> vec::sort renaming (which should be less
controversial, STL also has std::vector<T>::sort), the argument counting
trick won't be needed, the redirection will simply be:
#undef qsort
#define qsort(base, n, sz, cmp) qsort_chk (base, n, sz, cmp)
> I mean, isn't it better to just add a static inline qsort that in the
> checking case calls qsort_chk,
(redefining qsort like that is formally UB, I'd like to avoid it)
> or do the redirection using GNU asm redirection:
> typeof (qsort) __asm ("qsort_chk");
> and define extern "C" qsort_chk somewhere?
> configure could test whether it works on the target (it wouldn't perhaps
> on targets which already use some inline for qsort in their headers or use
> qsort as a macro (but the latter wouldn't work anyway with GCC already)).
I'd rather not go this way.
> The _5th macro isn't that bad either, appart from using reserved namespace
> identifiers (it really should be something like qsort_5th and the arguments
> shouldn't start with underscores).
I didn't understand what Jeff found "ugly" about it; I wonder what epithets
would be applied then to more, ahem, unusual parts of GCC.
Thanks.
Alexander