--On Saturday, August 28, 2010 12:56:15 AM +0200 Arnt Gulbrandsen
<arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no> wrote:
> On 08/24/2010 12:10 PM, Stephan Bosch wrote:
>> The alternative approaches/ideas I've seen/had thus far include:
>
> A fourth possibility is to get rid of runtime errors, which isn't as hard
> as it sounds.
You're kidding, right?
Since runtime errors may be environmental and/or data-dependent,
eliminating them entirely is virtually impossible.
Even if you ignore the data dependency issue and reject all scripts that
_could_ lead to a runtime error given the proper inputs (which I don't think
you're allawed to do), this is still an intractable problem.
Since Sieve suppports boolean expresions of arbitrary complexity, determining
whether or not a given statement will be reached is equivalent to the
satisfiability (SAT) problem. Cook showed that SAT is NP-complete.
So the best you can do is try and catch as many errors as possible when the
script is stored. But this in turn depends on having complete control
over Sieve storage. Sometimes this is operationally achievable, e.g., everyone
accesses storage through managesieve. But lots of times it isn't, e.g, Sieves
are stored as one field in a user database.
Ned
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve