Philip Hazel wrote:
> On Tue, 2 Jan 2007, Dean Brooks wrote:
>
>
>> Actually, what I was hoping for is that all this nonsense of checking
>> for valid integers in comparisons be removed, or at least allow a null
>> value to be used. I can't recall such an incompatible change in Exim
>> since the release of Exim 4.
>>
>
> My apologies. It was not meant to be such an incompatible change! The
> ChangeLog entry for the change that did this is:
>
> PH/07 There was no check for overflow in expansions such as ${if >{1}{4096M}}.
>
> The new behavious was a side-effect of refactoring in order to implement
> an overflow check. However, previously, Exim would notice non-integer
> strings such as "abc" and diagnose them if an integer operation was
> requested. It was just that the code for doing that was broken for an
> empty string.
>
> The "not totally logical, but does what a lot of people want" fix would
> be to treat an empty string as "0". A simple patch to do that (but I
> haven't tested it) is
>
> ------------------------------------------------------------------
> *** expand.c Tue Jan 2 10:18:17 2007
> --- expand.c Wed Jan 3 10:15:46 2007
> ***************
> *** 5499,5504 ****
> --- 5499,5505 ----
>
> errno = 0;
> expand_string_message = NULL; /* Indicates no error */
> + if (*s == 0) return 0;
> value = strtol(CS s, CSS &endptr, 0);
>
> if (endptr == s)
> ------------------------------------------------------------------
>
> Do people think it is reasonable to re-institute this special behaviour?
> If so, I will do so and document it for the next release.
>
>
> On Tue, 2 Jan 2007, Jakob Hirsch wrote:
>
>
>> This is actually the same issue. The change in 4.64 was compliant to the
>> spec, the old behaviour was an undocumented feature (aka: bug).
>>
>
> Indeed.
>
>
>> I agree the change for empty strings is [not] very good. OTOH, using
>> an empty string in integer comparisons is definitely a config flaw.
>>
>
> That is the dilemma. It seems that it is a common practice.
>
> On Tue, 2 Jan 2007, Dean Brooks wrote:
>
>
>> 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
>>
>
> There are no "integer variables" in Exim, because all variables hold
> strings (as seen by the user).
>
>
>> 2. There is no simple test to determine if a value is an integer
>>
>
> What you mean is "if a string is a representation of an integer". We do
> have ${if isip{...} so I suppose ${if isint{...} is a reasonable
> addition. The ... doesn't have to be just a single variable insertion;
> it could be any kind of string expansion.
>
>
Phil, my thinking is to make it work in a way that seems natural to the
end user. Looking at the user's expectations and the amount of support
it would generate. You have string functions and numeric functions in
Exim. Regardless of how you store these variables internally I believe
it is reasonable to treat null variables in string functions as an empty
string and null variables in numeric variables as zero.
My reaction to this is not to upgrade till it's fixed because I'd have
to wonder if I'm going to break anything if I do. Software should be
designed around what the user would expect rather than what's easy to
code. If you don't make null = 0 then you're going to get a lot of
support questions about it.
My 2 cents.
