[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#6437) sl_malloc issues
hyc@symas.com writes:
> Go ahead and commit. In working pieces if necessary. We'll pick and choose...
Thanks. Will do.
> Nobody uses the pool code. I would suggest you profile it against the stack
> code before spending any time fixing it.
Right, that and detach was what I wondered most about. Beyond just
"with enough changes, some will be bugs":-)
Well, the current pool code blocks the "ber_len_t -> 32-bit" space
optimization, which would import the alignment problem to 64-bit hosts.
Will profile first. When I get time.
>> * Regarding code duplication, the #ifdef SLAP_NO_SL_MALLOC code
>> duplicates the !ctx code. Make that if(<enum No_sl_malloc> && !ctx)
>> and the #ifdefs can be killed.
>
> I would personally prefer no runtime checks, and all compile-time checks.
Right, but if(compile-time constant) is a compile-time check on a decent
compiler. Otherwise we shouldn't be using '#define foobar do { ... }
while(0)' trick to allow ';' after a macro.
--
Hallvard