[Date Prev][Date Next]
Re: struct berval comparison
Howard Chu wrote:
> > -----Original Message-----
> > From: owner-openldap-devel@OpenLDAP.org
> > [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Pierangelo
> > Masarati
> > I'd like to avoid any unnecessary str[case]cmp on berval->bv_val,
> > so I added three functions, ber_memcmp(), ber_cmp() and ber_casecmp()
> > that are meant to replace memcmp, strcmp and strcasecmp respectively
> > when bervals are involved.
> > However their behavior in my implementation differs from that of the
> > replaced functions, because what I basically want to detect is match
> > without affecting ordering issues, so their use should be careful.
> > the match is:
> > if the lengths differ, return l1-l2; otherwise return the comparison
> > on the values.
> > 1) is this acceptable, are there comments?
> > 2) is the naming OK, any suggestions before I heavily modify the code?
> I converted entry_dn_cmp and many other of the AVL sort functions to
> behave this way already. It's fine when we want a sorted order but we
> don't care that it is lexicographic; it's much faster to compare bv_len
> first and avoid strcmp if we can. And obviously it's also fine for a
> straight is/is not match.
> In general I would not create these functions though; I would define
> them as macros that use the standard libc memcmp/strcasecmp if needed,
> simply because the libc routines are likely to be well optimized, and
> using a macro avoids the function call overhead if the *cmp() is unneeded.
> That's my (not so humble }-) opinion...
That's what I initially made with dn_match; I initially favoured the
function call to be able to assert the args, but I understand it's
a pin from performance standpoint, and this kind of bug is easy to trace
without assertins (the code is flawed anyway if you send a NULL to
I'll revert to macros then.A
Dr. Pierangelo Masarati | voice: +39 02 2399 8309
Dip. Ing. Aerospaziale | fax: +39 02 2399 8334
Politecnico di Milano |
via La Masa 34, 20156 Milano, Italy |