Re: [exim] More integer annoyances in 4.65

On Wed, Jan 03, 2007 at 05:06:54PM +0000, Dave Evans wrote:
> On Wed, Jan 03, 2007 at 08:46:28AM -0800, Marc Perkel wrote:
> > A null and a blank string are not the same thing either. Are you going
> > to treat strings that way too?
>
> Not a fair comparison IMO, because although variables can be null, the result
> of string expansion can (AFAIK) never be null. (e.g. h_Cc may be null, but
> expanding $h_Cc: yields the empty string). Since the operands of string ops
> (e.g. eq) are always acquired by first performing a string expansion, which
> can *only* yield a (possibly empty) string, the operands can never be anything
> but strings. Unless I've missed something.

Exim has no concept of nulls in its string expansions, only blank
strings. The word "null" should not be used in this discussion as
nulls do not exist in the constructs being discussed. That is, Exim's
"def:" condition simply tests to see if the variable is equal to an
empty string.

That being said, empty strings in integer comparisons seem completely
reasonable given that Exim is *already* doing a conversion from string
to integer form in this process.

By documenting that an empty value is equal to zero, and informing the
user to be aware of this and to depend on it seems completely
reasonable. Especially if it helps avoid breaking otherwise simple
expressions and confusing the heck out of new users.

--
Dean Brooks
dean@???