[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: An optimization for another day (and developer)
> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga
> At 07:05 AM 2001-12-28, Pierangelo Masarati wrote:
> >> BTW, one optimization I intended to implement but haven't
> >> the time is to allow:
> >> struct berval bv = { 0, NULL }
> >> struct berval *bvp = &bv;
> >>
> >> rc = dnPretty( NULL, &dn, &bvp );
> >> rc = dnNormalize( NULL, &dn, &bvp );
> >>
> >> That is, allow call to provide, optionally, a
> >> pre-allocated struct berval instead of relying
> >> on the caller to malloc on up. Of course, in
> >> some cases, the existing behavior is preferred.
> >
> >I note that relying on developers (I speak mostly of myself :)
> >to supply a NULL pointer if alloc is required or non-NULL pointer
> >if it can be safely used is dangerous: no more than five minutes
> >ago I fixed this bug in back-monitor. I'd rather use a alloc/use
> >flag in an ancillary function, or radically change the API
> >to accept only pre-allocated structs, which wouldn't be a big issue
> >since the big allocation takes place for the bv_val, not for the
> >struct berval.
>
> Yes, that's a consideration. One approach is to have two
> prototypes, one expecting a struct berval *, the other a
> struct berval **... with the latter being a wrapper which
> did the allocation before calling the former...
I could go with that. In the majority of the cases, there is no
reason to allocate the destination berval. (The only place I've
seen it needed is when the result is then saved with ber_bvecadd,
which is mainly config.c building suffix arrays.)
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support