On Thu, Aug 03, 2017 at 09:33:13AM -0600, Jeff Law wrote:
> On 08/03/2017 08:24 AM, Alexander Monakov wrote:
> > On Wed, 2 Aug 2017, Jeff Law wrote:
> >>>> Well, there's not *that* many qsort calls. My quick grep shows 94 and
> >>>> its a very mechanical change. Then a poison in system.h to ensure raw
> >>>> calls to qsort don't return.
> >
> > Note that poisoning qsort outlaws vec::qsort too; it would need to be mass-
> > renamed as well (to vec::sort, presumably). It seems there are 83 or more
> > calls to vec::qsort.
> Ugh :( That's an unfortunate implementation of poisoning :( Consider a
> patch to rename those too pre-approved.
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.
I mean, isn't it better to just add a static inline qsort that in the
checking case calls qsort_chk, 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)).
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).
Jakub
