Quoting Dean Brooks:
>> ${if >{${spam_score_int}0}{500}}
>> ${if >{${acl_m}0}{1000}}
> I see why that works, but that is really a hack IMO. The average user,
> and perhaps the more advanced user, may not see that as an obvious
> way to handle it.
Right. I'm just relaying what I was told back then.
>> I agree the change for empty strings is very good. OTOH, using an empty
^
oops, that should have been "not very good".
>> string in integer comparisons is definitely a config flaw.
> I disagree. I believe that casting is a useful construct if the behavior
> is defined and can be depended on. Having a null value equate to 0
> when cast to an integer is a sane and logical operation. Again, IMO.
It's not that easy. spam_score_int being 0 is not the same as being
empty. In this special case it probably does not matter in most cases,
as you usually test for positive values, but that may be different for
other variables.
> However, I have no problems with the new implementation. The only issue
> I have is two-fold:
>
> 1. There are integer variables that can have a blank value
How should this be handled? SQL has NULL for that, which is always false
when comparing it to anything (including NULL itself), except when using
the IS NULL test. In exim, you can use def:
> 2. There is no simple test to determine if a value is an integer
> Adding those two should help users migrating to the new format.
Again, this has nothing to do with "new" or "old" format. AFAIK, exim
always complained about non-numeric characters in integer tests and it
seemed not to be missing.
