Mailing List Archive: [Bug 474] ACL condition to unset a variable

------- You are receiving this mail because: -------
You are the QA contact for the bug.

http://bugs.exim.org/show_bug.cgi?id=474

Roman Odaisky <to.roma.from.eximbug@qwertty.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |to.roma.from.eximbug@qwertty
| |.com

--- Comment #10 from Roman Odaisky <to.roma.from.eximbug@qwertty.com> 2008-09-01 10:49:56 ---
Both proposed changes are quite important, especially isset.

In many cases one needs to distinguish between variables containing the empty
string and nonexistent variables. Of the predefined variables, $spam_bar comes
to mind: it can be empty for ham messages, or it can be undefined before spam
testing takes place. Or some conditions can be cached, as in:

some_acl:

warn
condition = ${if !isset:acl_m_some_acl_result}
set acl_m_some_acl_result = ${if some-heavy-condition}

accept
condition = $acl_m_some_acl_result

deny

It wonâ€™t work with def:..., because that treats empty and unset variables the
same.

The problem is aggravated by strict_acl_vars, with which one canâ€™t check for
unset variables at all.

unset would also be useful, though to a less extent. The idea is not to spare
resources, but to add more expressive possibilities. For example, the caching
ACL above can unset the variable under certain conditions to force
re-evaluation. The problems with removing tree nodes are solvable, I guess the
tree is basically what C++ would call std::map<std::string, std::string>? The
C++â€™s map can remove elements easily, your tree should allow that as well.

To summarize, isset is really needed, especially for those who use
strict_acl_vars. unset would also be helpful.

--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email
--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

Hi,

first, please let us discuss this on exim-dev, bugzilla is not a
discussion forum.

> Both proposed changes are quite important, especially isset.
>
> In many cases one needs to distinguish between variables containing the empty
> string and nonexistent variables. Of the predefined variables, $spam_bar comes
> to mind: it can be empty for ham messages, or it can be undefined before spam
> testing takes place. Or some conditions can be cached, as in:

You can easily look at $spam_score* to see if $spam_bar contains
something valid.

> warn
> condition = ${if !isset:acl_m_some_acl_result}
> set acl_m_some_acl_result = ${if some-heavy-condition}

condition = ${if !def:acl_m_some_acl_result}
set acl_m_some_acl_result = ${if some-heavy-condition {yes}{no}}

I see that it's more to type. And that it was a questionable decision to
expand false ${if..} to the empty string, when the short format of it
was introduced.

> The problem is aggravated by strict_acl_vars, with which one canâ€™t check for
> unset variables at all.

strict_acl_vars was intended for detecting typos. If you want to use it,
I would suggest to set all variables you want to use as early as
possible to the empty string (which is essentially like using the "my"
function in perl, which you need when using "use strict", therefore the
name strict_acl_vars).
btw, strict_acl_vars would inhibit the use of your "isset:" operator,
because testing for an unset variable would result in an expansion error.

> unset would also be useful, though to a less extent. The idea is not to spare
> resources, but to add more expressive possibilities. For example, the caching

As shown, this is already possible.

> re-evaluation. The problems with removing tree nodes are solvable, I guess the
> tree is basically what C++ would call std::map<std::string, std::string>? The
> C++â€™s map can remove elements easily, your tree should allow that as well.

Of course it's solvable. But exim is not written in C++, and we would
need to add complex code for no real benefit.

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##