I've been sent a small patch that changes Exim so that it allows the use
of real numbers in filters, i.e. statements like
if $h_something: is above 3.5 then ...
Currently only integers are supported. The motivation for the patch was
for handling spam scores that are real numbers.
The patch itself is small, but there is a principle at stake here. Apart
from load level values, and the multipliers in G retry algorithms and
ratelimit parameters (which are fixed point numbers), all the numbers
that appear in an Exim configuration or filter file are integers.
If the above filter statement is made to work, will people expect
${if > {$h_something:}{3.5}{...
to work? I rather think they will.
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.
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...
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).
Views, please.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
