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

[Tim Howes <howes@netscape.com>]

You don't want to do this. Not so much because it may not
have been malloc'ed the way you thought (we could mandate
this), but because a different version of malloc/free may be
in use by the ldap library than is in use by your program.
That's why routines like ldap_value_free() and ldap_memfree()
exist.                                             -- Tim

Hallvard B Furuseth wrote:

> 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