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

Quoting Nico Erfurth:

> .... just had a look at the current code (damn, it's a long time ago
> since i had a look at the exim code *G*) it seems like the recent(?)
> change to use -aclm and -aclc in favor of -acl didn't care for this
> problem either, so maybe a wrote a lot of useless text *G*.

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).

>> I'm not sure if using store_release if a variable is redefined is
>> correct, but it's easy to remove that. The existing aclvar code does not
> It would be better to check the size of your current value and maybe
> overwrite it if it fits, store_release is only able to release store if
> it is on top of the stack.

I've seen no function in store.c which tells me the size. I could put it
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").

>> To find a variable, I use a simple linear search, which is not the most
>> efficient method (euphemism alert!), but as most people only use a few
>> variables there's is really no need for a bloated hash function with
>> collision handling. And many people do just the same with files...
> Exim already includes code for balanced trees, check tree.c.

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. :)

> And you don't seem to know the exim community very well, they will use
> new features until something breaks *G*

Nothing will break, of course. :)