Re: commit: ldap/libraries/libldap getdn.c

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 11:28 PM 2001-12-02, Pierangelo Masarati wrote:
>> Update of /repo/OpenLDAP/pkg/ldap/libraries/libldap
>> 
>> Modified Files:
>>       getdn.c  1.38 -> 1.39
>> 
>> Log Message:
>> small improvements and fixes; now honors ';' as rdn separator in LDAPv2 mode
>
>One improvement I forgot to mention in the log string is the
>presence of a WILLESCAPE macro that selects those chars which
>do not striclty require escaping but we want to for optimization
>purposes (e.g. commas and maybe plusses in the evaluation of 
>regex's dn patterns).
>
>There's one major issue in using this stuff to re-engineer 
>dn_normalize/dn_validate: it does not work in place, that is
>the string representation of ldap_dn2str(ldap_str2dn(dn_in))
>is in newly allocated memory.

The plan is to move to using new functions:

dnValidate
        checks that the input is a valid DN
dnNormalize (creates a DN for matching)
        outputs a value suitable for dnMatch matching (and indexing)
dnPretty
        outputs a "pretty" DN

For migration purposes:
  dn_validate needs to be written in terms of dnPretty().
  dn_normalize is already written in terms of dnNormalize().

The DN pretty form should be designed such that in most cases
it is shorter than its input.  Where not, an error can be returned.

>I planned to introduce a layer of functions working with given
>buffers to allow in-place work with limited overhead (of couse
>we can do
>        DN = ldap_str2dn(dn_in);
        <schema aware mucking inserted here (eventually)>
>        dn_out = ldap_dn2str(DN);
>        free(DN);
>        strcpy(dn_in, dn_out);
>        free(dn_out);

That would be dnPretty()

>The only solution I envisage is to change the api 
>of dn_normalize/dn_validate; in the meanwhile we should make 
>sure these functions are called as soon as possible and not
>used on already normalized DNs, as Kurt said in
>http://www.openldap.org/lists/openldap-devel/200111/msg00014.html

See my suggestion above.  That is, write dn_validate/dn_normalize
in terms of the new functions while migrating to dnValidate,
dnNormalize, dnPretty, and dnMatch functions.

>As soon as the structural representation of the dn may be useful
>in many places where non-trivial dn construction is required 
>(e.g. in modrdn functions) we might create a DN structure that
>contains both the structural representation (which is built the 
>first time the dn is parsed) and the string representation
>as rebuilt from the sructural representation, in a berval.

>This should reduce the amount of normalizations/strlens on
>DNs.

Yes, eventually we need to pass LDAPDNs...