Re: (ITS#6437) sl_malloc issues

[h.b.furuseth@usit.uio.no]

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