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

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

At 01:48 AM 2001-12-05, Stig Venaas wrote:
>On Tue, Dec 04, 2001 at 07:11:57PM +0100, Pierangelo Masarati wrote:
>> Done. Now another migration problem arises.  The normalization
>> function at present does not uppercase the DN, so all the code 
>> that uses strcmp (a lot!) when comparing normalized DNs is broken.
>> There are two solutions: 
>> a) tweak the new dn_normalize to make it uppercase the resulting 
>> string (already tried, works fine)
>> b) add a dn_match wrapper that calls dnMatch (which on turn uses
>> strcasecmp as a temporary hack), and replace all the strcmp around
>> the code (I started doing this, but it's kinda a nightmare; if 
>> we're not going to use dnMatch all around the code, relying on 
>> appropriate uniform normalization, I'd prefer solution a).
>> So I'd rather wait for suggestions before I keep on replacing
>> strcmp's all around (adding an extra set of strlen's because
>> dnMatch uses berval's ...)
>To me it seems reasonable to tweak dn_normalize. In addition to do
>case folding you should also do Unicode normalization. The old
>dnNormalize() did this using UTF8normalize( val, UTF8_CASEFOLD ).

Likely this be done in dnNormalize upon the RFC2253 string
until we actually implement the schema aware normalization.

>You cannot simply use strcmp (you must pay attention to Unicode
>when doing case folding), and if you want to do both Unicode
>normalization and case folding, doing this with UTF8normalize()
>is faster than doing it as separate operations. I don't know much
>about this, but I would guess that one should normalize each
>attribute value in the DN separately depending on the syntax, and
>not do Unicode normalization (or strcmp) on the entire string. But
>maybe it still works and is faster to do it on the entire DN?