Fw: [Q] attr.c bug?

["Alex Zeltser" <alex_zeltser@securecomputing.com>]

I think the same issue comes up with schemaparse.c/parse_oc_old, and
possibly others?

Is there a convention for which memory functions should be used when?  Are
we in the middle of switching approaches?

Thanks a lot,

Alex

----------
> From: Alex Zeltser <azeltser@safeword.com>
> To: OpenLDAP Development <openldap-devel@openldap.org>
> Subject: [Q] attr.c bug?
> Date: Monday, June 07, 1999 3:27 PM
> 
> Just came across something that seemed strange.  I'm doing some testing
> with the NT port of slapd.  In attr.c, in attr_syntax_config the variable
> 'at' is allocated with a call to ch_calloc.  In the case of an error it
is
> freed a few lines later with a call to free; in the case of no error, it
is
> freed at the end of the function with ldap_memfree (which in turn calls
> ber_memfree).  Looking at implementations of ch_calloc and ber_memfree,
it
> appears that the two are not compatible.  It seems ok to call free on a
> ch_calloc'ed ptr, but not ber_memfree.  In my case, this triggered an
> assert.  Has  noone else run into this?  (It seems that the use of three
> potentially different memory management functions on the same pointer is
a
> little risky, or is it just me?)
> 
> (As an aside, why does attr_syntax_config even need to alloc at off the
> heap, if it's always freed upon function exit?  Why not just declare it
as
> a stack variable and be done with it?  Am I missing something?)
> 
> (As another aside, are ch_xalloc functions meant to only be used for
> allocations that _must_ succeed for the program to function properly? 
They
> all see to call 'exit' on allocation failures which seems a bit extreme
> under normal conditions.)
> 
> Thanks,
> 
> Alex Zeltser
>