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