Re: [exim] More integer annoyances in 4.65

Góra strony
Delete this message
Reply to this message
Autor: Philip Hazel
Data:  
Dla: Exim Mailing List
Temat: Re: [exim] More integer annoyances in 4.65
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.

-- 
Philip Hazel            University of Cambridge Computing Service
Get the Exim 4 book:    http://www.uit.co.uk/exim-book