RE: ldap-c-api: malloced vs. "ldap alloced" data

["Salter, Thomas A" <Thomas.Salter@unisys.com>]

I think the alternate implementation you give below should be legal.
It's possible that the api might be able to just give pointers into the
orginal Ldap result buffer.  In that case, the api would avoid a malloc
of buffer[s] for all the strings and the copying of all the strings.

> ----------
> From: 	Hallvard B Furuseth[SMTP:h.b.furuseth@usit.uio.no]
> Sent: 	Wednesday, February 25, 1998 5:32 PM
> To: 	ietf-ldapext@netscape.com
> Subject: 	ldap-c-api: malloced vs. "ldap alloced" data
> 
> I have several programs (written by both me and others) that trust
> ldap_value_free(array) to be implemented as
> 
>     free() each element in <array>;
>     free() <array> itself.
> 
> That is, they do things like
> 
>     - rearrange (e.g. sort) and maybe free() some of the strings
>       in the array returned by ldap_get_values().
> 
>     - build a fake ldap_get_values() return value.
> 
> The draft does not promise that this is OK.  Do we want it to?
> 
> If not, some of my programs must copy most output of ldap_get_values()
> to an equivalent private array which *is* double-malloced as above.
> Easy enough, but wasteful.
> 
> 
> Example of an implementation which breaks the assumptions above:
> 
> ldap_value_free(array):
>     free(array[0]);	/* One malloced array with all the strings */
>     free(array);	/* ...and poiners into that array */
> 
> ldap_explode_*dn() and ldap_get_values():
>     char **array = malloc(<big enough>), **ap = array;
>     char *text   = malloc(<big enough for all the strings>), *tp =
> text;
>     for (char *val = <first>; val; val = <next>) {
>         *ap++ = strcpy(tp, val);
>         tp += strlen(val) + 1;
>     }
>     *ap = NULL;
>     return ap;
> 
> -- 
> Hallvard
>