On Mon, 7 Aug 2006, Jakob Hirsch wrote:
> 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.
;)
> I've seen no function in store.c which tells me the size. I could put it
There is none, the exim memory manager is very simple, but effective, if
used correctly.
> 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}
(I didn't use the expansion language for some time now, so i hope the
example is correct)
People tend to do the strangest things with exim. You don't wanna know
what kind of questions I get these days, even after I wasn't active in the
exim community for a loooooong time now.
> 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
....).
> Nothing will break, of course. :)
Very selfconfident the young jedi is. ;)
Nico
--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details
at http://www.exim.org/ ##
