(ITS#5286) NULL value in sets

[raphael.ouazana@linagora.com]

Full_Name: Raphael Ouazana
Version: HEAD, RE24, RE23
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (164.2.255.244)


Hi,

I repost this here as I think the discussion was lost in a closed ITS (#4860).
The two solutions (other operation or previous behavior) would be fine for us,
but I have not really time to make a patch for the moment.

Le Sam 10 novembre 2007 16:37, ando@sys-net.it a .crit :
>> Below I represent sets in {element1, element2} notation, to describe
the
>> current behaviour (in HEAD) for slap_set_join on the '+' operation:
>> - {"One", "Two"} + {"Three", "Four"} ==> {"OneThree", "OneFour",
>> "TwoThree", "TwoFour"}
>> - {"One", "Two"} + {""} ==> {"One", "Two"}
>> - {"One", "Two"} + {NULL} ==> {"One", "Two"}
>
> Although sets lack a specification, I think this behavior is desirable
> in many cases: adding NULL is equivalent to adding EMPTY ("").

The problem is that {NULL} is equivalent to NULL, ie the empty set.

>> Consider the following set:
>> set="[ldap:///] +
[ldap:///<searchbase>??<scope>?<filter1>] +
>> [??<scope>?<filter2>]"
>>
>> Assuming [ldap:///<searchbase>??<scope>?<filter1>]
returns a DN, this
>> works. However, if
[ldap:///<searchbase>??<scope>?<filter1>] returns no
>> entries, this value is NULL. Therefore, the rest of the set becomes:
>> "[ldap:///] + {NULL} + [??<scope>?<filter2>]"
>> ...which is handed to the '+' operation in slap_set_join, to become:
>> [ldap:///??<scope>?<filter2>]
>> ...which obviously isn't valid.
>
> Well, it is valid: it's an URI with an EMPTY DN.

In terms of LDAP, yes, but it can cause security issues here, as the EMPTY
DN is at a higher level that any one which would have been returned by a
normal result.

>> The attached patch changes the last case of the current behaviour for
>> slap_set_join on the '+' operation. This was already the behaviour
>> before version 1.24.2.6 Thu Sep 13 20:43:29 2007 UTC:
>> - {"One", "Two"} + {NULL} ==> {NULL}
>
> This is different from the above behavior, although it makes sense on
> its own.  Probably we need two different addition operators: one
> inclusive (NULL is equivalent to "") and one exclusive (NULL nullifies
> the concatenation).
>
> Comments?

No problem in having the two operators.  I just think the normal behavior
is to return NULL, has in term of sets the cartesian product A x NULL
returns NULL, not A.

Regards,
Raphael Ouazana.