Re: [exim-dev] patch for named acl variables

Quoting Nico Erfurth:

>> I think you have a point, but changing the keyword will not help. As you
>> wrote, old versions will not detect the new keyword, skip the line, but
>> bail out on the next line. One way to prevent that would be to put the
>> value in the same line (and encode line feeds). But then people wouldn't
>> notice that some variables are suddenly lost, which they probably rely
>> on. With exim complaining about broken queue files, they can at least
>> fix them by replacing the name with the number they used before (not
>> only the spool files, but also in the config and all the filter files).
> They would notice, because exim will complain about an unknown variable.
> ;)

Um, no, the current code skips unknown keywords in spool files. So, if
the whole variable's information is in a single line, an old version
will simply skip it and the variable is lost.

>> in the acl_named_var struct, but I have the feeling that this is not
>> really necessary (and was we all know, "premature optimization is the
>> root of all evil").
> I don't think it's necessary either, but memory can pile up in some
> configurations.
> Just think of something like
> set acl_c_myvar = ${eval: $acl_c_myvar + 1}

Yes, that was also my concern. But the code for numbered variables
simply allocates new storage space. I'm hesitant to change the
established behaviour if it never raised problems.

>> I thought there must be something, but wanted to keep it simple and
>> therefore not use some bloated API, but this looks nice. Again, I think
>> it's not really needed, but if it helps to get this into Exim, I will
>> happily do it. This would even simplify my own code. :)
> It's used in some places in the code (and maybe could be used in more
> ....).

Ok, there seems to be some consensus to consolidate named and numbered
vars, so I'll rework the code to do that and use btrees. Let's see what
Philip will say about it.