parsing in-place (was RE: where has ber_bvdup() gone?)

["Howard Chu" <hyc@highlandsun.com>]

By the way, this change yielded about a 9% reduction in mallocs overall and a
3% speed increase for searches. Unfortunately it was not really applicable to
adds because back-ldbm takes the given entry and stores it in its entry cache
as-is. (So if the values were not copied out of the BerElement, they were
destroyed when the operation ended and the BerElement was freed. Not a pretty
sight...)

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

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

> > -----Original Message-----
> > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
>
> > I note that one of the reasons that strings are copied out of
> > the BER data is to null terminate them.  A properly designed
> > API would return pointers and length to non-null terminated
> > strings, yet provide routines for converting to null terminating
> > strings when applications desire such.
>
> That's not strictly necessary. All the work can be done in-place
> with some minor changes - in ber_get_next, the ber_buf should
> be allocated with size ber_len+1 instead of ber_len, to allow
> null-termination of the last element. Every preceding element can
> be null-terminated by overwriting the following tag. The tag just
> needs to be stashed away inside the BerElement before being overwritten,
> and ber_peek_tag/ber_skip_tag/ber_get_tag modified accordingly.
>
>   -- Howard Chu
>   Chief Architect, Symas Corp.       Director, Highland Sun
>   http://www.symas.com               http://highlandsun.com/hyc
>   Symas: Premier OpenSource Development and Support
>