This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 6/6] qsort comparator consistency checking
On 08/03/2017 09:52 AM, Jakub Jelinek wrote:
> 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.
Thinking about this again, you're probably right. I failed to
distinguish between this case and something like malloc. For qsort, if
we're using the numbering hack, introduction of a new qsort call will
result in a qsort call that is properly checked. In contrast we simply
don't want folks calling malloc & friends directly under any circumstances.
Sorry for taking everyone down a bogus path here.