On 08/10/2017 05:24 AM, Alexander Monakov wrote:
> On Wed, 9 Aug 2017, Jeff Law wrote:
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
On Wed, 9 Aug 2017, Jeff Law wrote:
> >> 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;
On 08/03/2017 10:23 AM, Alexander Monakov wrote:
> 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
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
On 08/03/2017 05:23 PM, Alexander Monakov wrote:
> Note that with vec::qsort -> vec::sort renaming (which should be less
> controversial, STL also has std::vector::sort), the argument counting
> trick won't be needed, the redirection will simply be:
OTOH, std::sort's comparison function callback
On Thu, 2017-08-03 at 19:31 +0300, Alexander Monakov wrote:
>
> My mistake, but the main point remains: STL uses 'sort' without the
> 'q'.
I think it'd be better if GCC's custom containers somewhat tried to
follow C++ standard container idioms. Chopping off the 'q' is one step
towards it.
On Fri, 4 Aug 2017, Oleg Endo wrote:
> > Note that with vec::qsort -> vec::sort renaming (which should be less
> > controversial, STL also has std::vector::sort)
>
> No it doesn't? One uses std::sort from on a pair of random
> access iterators to sort a std::vector.
My mistake, but the main
On Thu, Aug 03, 2017 at 07:23:31PM +0300, Alexander Monakov wrote:
> 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
On Thu, 2017-08-03 at 19:23 +0300, Alexander Monakov wrote:
>
> Note that with vec::qsort -> vec::sort renaming (which should be less
> controversial, STL also has std::vector::sort)
No it doesn't? One uses std::sort from on a pair of random
access iterators to sort a std::vector.
Cheers,
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
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
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
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-
On 08/02/2017 12:00 PM, 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.
>
> Any suggestion for the
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.
Any suggestion for the non-poisoned replacement? xqsort? gcc_qsort?
Can you
On 07/15/2017 02:47 PM, Alexander Monakov wrote:
> This is the updated qsort comparator verifier.
>
> Since we have vec::qsort(cmp), the patch uses the macro argument counting
> trick to redirect only the four-argument invocations of qsort to qsort_chk.
> I realize that won't win much sympathies,
On 07/31/2017 12:27 PM, Alexander Monakov wrote:
> On Mon, 31 Jul 2017, Jeff Law wrote:
>> I must have missed something. Can't you just define
>>
>> qsort (BASE, NMEMB, SIZE, COMPARE) into
>>
>> qsort_chk (BASE, NMEMB, SIZE, COMPARE)
>>
>> That shouldn't affect the qsort from vec? Right? Or am
On Mon, 31 Jul 2017, Jeff Law wrote:
> I must have missed something. Can't you just define
>
> qsort (BASE, NMEMB, SIZE, COMPARE) into
>
> qsort_chk (BASE, NMEMB, SIZE, COMPARE)
>
> That shouldn't affect the qsort from vec? Right? Or am I missing something
If you do
#define qsort(base,
On 07/15/2017 02:47 PM, Alexander Monakov wrote:
> This is the updated qsort comparator verifier.
>
> Since we have vec::qsort(cmp), the patch uses the macro argument counting
> trick to redirect only the four-argument invocations of qsort to qsort_chk.
> I realize that won't win much sympathies,
This is the updated qsort comparator verifier.
Since we have vec::qsort(cmp), the patch uses the macro argument counting
trick to redirect only the four-argument invocations of qsort to qsort_chk.
I realize that won't win much sympathies, but a patch doing mass-renaming
of qsort in the whole GCC
20 matches
Mail list logo
