Re: [exim] More integer annoyances in 4.65

Top Page
Delete this message
Reply to this message
Author: Marc Perkel
Date:  
To: Tom Kistner
CC: exim-users
Subject: Re: [exim] More integer annoyances in 4.65


Tom Kistner wrote:
> Jakob Hirsch wrote:
>
>
>> The fix for your config would be:
>> ${if >{${spam_score_int}0}{500}}
>> ${if >{${acl_m}0}{1000}}
>>
>
> Yukk! :)
>
>
>> # /usr/sbin/exim-4.63 -be
>>
>>> ${if ={bla}{0}}
>>>
>> Failed: "bla" is not a number
>>
>
> Yes, but:
>
>
>> ${if ={$acl_m0}{0}{yup}{nah}}
>>
> yup
>
> Using pre-4.63, with $acl_m0 uninitialized.
>
> The change we made will break a very large number of configurations
> (including a few of my own), and I vote for restoring the previous
> behavior wholesale.
>
>
>> OTOH, using an empty string in integer comparisons is definitely a config flaw.
>>
>
> I agree, but in this case continuity is more important.
>
> /tom
>
>


I think you should go to the trouble to "do it right".

Doing it right mean that you give the user what they logically expect.
Thus if you are doing a numberic comparison and you get a null you
consider it a zero. If you do a string comparison and you get a null you
get an empty string.

Suppose you compared a null to an empty string? Technically they are not
equal. One could argue that a null and an empty string are different
because a null is nothing and an empty string is set to be empty. But
that would be confusing. Just as not making a null be zero in numeric
comparisons is confusing.