[Top] [All Lists]

Re: NULL vs. ""

2005-05-27 05:50:43

Kjetil Torgrim Homme writes:
On Fri, 2005-05-27 at 10:47 +0200, Arnt Gulbrandsen wrote:
 NULL and "" should be the same.

by NULL I assume you mean "undefined" or "not present".

I assume so too, but it doesn't necessarily have to be so ;)

If you'll look at draft-newman-comparator (currently expired) you'll see that "NULL strings" are mentioned in section 4.6, the behaviour of comparing, equality testing and substring testing on NULL strings is defined, but a NULL string itself is defined only implicitly as "a string that contains no characters and is not the same as an empty string".

In the context of sieve, that would seem to encompass the value of an absent header field, the value of a variable that is initialized from such a header field, etc.

it's hard to make a general comment, but it's clear that is not generally true in Sieve today. are you proposing to change the semantics of the header test?

I think I'm not.

I agree it's not generally true, but I'm not sure whether it's completely true.

I want to either kill NULL strings in the comparator draft or provide a raison d'etre in the form of a good example. Either is fine with me. And I want to be compatible with the established use of comparators.

If a header listed in the header-names argument exists, it contains the null key (""). However, if the named header is not present, it does not contain the null key. So if a message contained the header

           X-Caffeine: C8H10N4O2

   these tests on that header evaluate as follows:

           header :is ["X-Caffeine"] [""]         => false
           header :contains ["X-Caffeine"] [""]   => true

There are no null strings here, only empty strings, so I don't think it's relevant.

on the other hand, in the variables extension it is impossible to distunguish between an unset variable and a variable set to "".

And that sounds very much in tune with sieve...

To me it sounds as if requiring a distinction between NULL (whatever it is) and "" is a little too much of an imposition. Better to kill the NULL concept in comparators.


<Prev in Thread] Current Thread [Next in Thread>