Re: segfault in ldap_back_search() with ENABLE_REWRITE (ITS#2825)

[ando@sys-net.it]

>> where?  In any case, one of the reasons of using bervals
>> instead of char*s was exactly to avoid having to check for
>> NULL pointers and calling strlen() all the times.  Now
>> all struct berval*s should be assert()ed, and a null
>> berval'ed field should be tested as bv->bv_val == NULL while
>> an empty one should be tested as bv->bv_len != 0.  In my
>> opinion, a NULL base is totally meaningless; an empty base
>> makes sense.
>
> Ando,
> Is it your point that we should change bv->bv_val == NULL
> to bv->bv_len == 0 along with the related codes sometime ?
> Currently, berval library codes are also checking bv->bv_val
> when it could check bv->bv_len, and there are also some
> cases where bv->bv_len is left uninitialized, making its user
> codes unable to rely on bv->bv_len.
> - Jong

I wouldn't be so strict; however, the two things have different
meanings: bv_val == NULL means there is no value; bv_len == 0
means the value is empty, but it is a legal value.  So bv_len == 0
should be allowed to coexist with bv_val != NULL, e.g. in the
rootDSE, while bv_val == NULL should imply that bv_len must be
ignored.

The use of either form should be consistent with the meaning
of each berval.  For instance, a search base of { 0, NULL }
has little meaning, while a search base of { 0, "" } makes
sense.

This has nothing to do with the original posting, because
in that case the berval pointer was null; I'd consider this
occurrence undesirable, because it defeats the purpose of
using bervals as arguments.  Note that all this discussion
is outdated since the ABI change.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it