Re: [Exim] Opinions sought: real numbers in filters

> If the above filter statement is made to work, will people expect
>
> ${if > {$h_something:}{3.5}{...
>
> to work? I rather think they will.

Yes, since > is a numeric comparator, I would expect that.

> Should I make both these changes? I assume that the performance impact,
> when the numbers are in fact integers, will be fairly small. In fact, I
> suppose I could continue to use integers except when at least one of the
> numbers contains a decimal point.

I think everything should be stored as integer that really is an
integral value.

> If the changes are made, are people going to expect settings like
>
> message_size_limit = 5.6M
> return_size_limit = 1.5K
> command_timeout = 2.5s
>
> to work? In other words, how much of a can of worms is this? The slope
> seems *very* slippery...

Good point. I would expect the above to work and being equivalent
to:

message_size_limit = 5872026
return_size_limit = 1536
command_timeout = 2.5s

Sizes are integral values, timeouts are not. Assigning a floating
point value to an integral variable should assign the rounded value.
You could also truncate the fractional part, but rounding feels more
natural.

> An alternative approach to the original problem would be to provide an
> operator that turns a string representing a real number into
> "thousandths" (e.g. 3.5 -> 3500).

If anything at all, then introduce an eval operator for calculations
instead of a specialized scaling operator, please, but emulating fix-point
calculations that way looks ugly to me.

Today, the impact of introducing floating point comparisons should be so
small that nobody will notice it. Things were different 15 years ago,
where one would have thought twice about linking the half of the math
library just for one strtod(). There are probably a number of places
in Exim that need to be touched for the patch, but all in all, the code
should not get bigger or more complicated (famous last words:).

Michael