[Date Prev][Date Next] [Chronological] [Thread] [Top]


Howard Chu writes:
> 2) APIs for operations must have a function parameter for every operation
> protocol parameter. (E.g., current ldap_search variations all omit DEREF, so
> you can only specify this via ldap_set_option. Ugly.)
>   2a) Functions with long parameter lists are difficult to manage. Perhaps
> use request structures/parameter blocks, like 2.2 slapd.

And/or make some simplified functions that default parameters that are
often unused, like controls.

>   2b) Caller must provide storage for pointers-to-results. (E.g., no
> mallocing struct bervals to return a berval to caller.)

I disagree completely.  Memory must be malloced anyway, because we don't
know the size of the bv_val to be malloced, or the number of berval*'s
to malloc in a berval** array, or whatever.  If part of a structure is
owned by the caller and other parts by the library, it will be messy
to keep track of such ownership and how the memory is to be freed.  In
particular if a such a structure is inserted into a larger structure,
which then can't be freed with one simple operation.