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

RE: where has ber_bvdup() gone?

> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Pierangelo
> Masarati

> > Actually, it turned out that one of our libraries (licensing library)
> > was built against an older version of OpenLDAP.
> >
> > Which raises the question - was it really necessary to break the
> > binary ABI? Or was ber_bvdup() not specified by the C API draft
> > (I admit to not having checked)?
>
> I guess you're right.  That hack came out of an optimization Howard Chu
> recently added; I think he decided to replace the function with a macro
> to delay (maybe forever) the replacement of many calls throughout the
> code. I checked the draft-ietf-ldapext-ldap-c-api-xx.txt and the function
> is mentioned; this will possibly require replacing the calls to ber_bvdup()
> and deleting the macro.

Sorry, I had not checked the draft. Note however that the latest draft expired
April 8 2000, quite a long time ago. If it were still a viable document, I
would post some suggestions to the IETF working group to
replace all use of ber_bvec-whatever. The use of struct berval **'s and ***'s
everywhere is just a waste of time and memory. Any time your application spends
more than 50% of its time in the C library instead of doing your application,
you know something's seriously broken. This C API spec causes just that.

What amazes me is that the C API authors never bothered to stop and think about
what they were doing; arrays of pointers are fine, but why exactly do you need
the pointer? In this case, you need pointers to dynamically allocated character
data. All the rest is of fixed, known size and should have been treated as such
from the beginning. There was absolutely no usability benefit from the
pointer-to-pointer construct. In fact it was quite an annoying hindrance, just
think of that nonsense with "struct berval val, *vals[2]" everybody had to go
through with attr_merge...

The whole allocate-and-copy-everything approach is pretty broken to begin with.
Strings returned from liblber ought to be parsed in place in the existing Ber
buffer; just return the pointer and length. Then you don't even need a
ber_bvfree() function because there is no alloc to clean up.
There are plenty of other libraries out there defined this way - memory given
to you by the library is the library's responsibility to clean up, not yours.

> Consider however that this is HEAD code; the macro could also be confined
> to the server.

There is a single use in clients/tools/ldapmodify.c.

> Ando.

Thanks for fixing things up with the replacement ber_bvdup function. We should
not break binary compatibility, even if the existing spec is ill-conceived and
expired.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support