[exim-cvs] Bug 1518: fix description of condition processing

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Exim Git Commits Mailing List
Ημερομηνία:  
Προς: exim-cvs
Αντικείμενο: [exim-cvs] Bug 1518: fix description of condition processing
Gitweb: http://git.exim.org/exim.git/commitdiff/d69645bc124ce675326b0778d261962791855b38
Commit:     d69645bc124ce675326b0778d261962791855b38
Parent:     82dbd376b5de9b9d91e93e91a4e058a80a43de99
Author:     Todd Lyons <tlyons@???>
AuthorDate: Thu Sep 4 11:20:31 2014 -0700
Committer:  Todd Lyons <tlyons@???>
CommitDate: Fri Sep 5 22:16:20 2014 -0700


    Bug 1518: fix description of condition processing


    The description in the first commit was completely wrong.  Thanks to
      Phil for setting me straight and seeding me with the correct verbage.
---
 doc/doc-docbook/spec.xfpt |   27 ++++++++++++++++++---------
 1 files changed, 18 insertions(+), 9 deletions(-)


diff --git a/doc/doc-docbook/spec.xfpt b/doc/doc-docbook/spec.xfpt
index ffe153a..2a52666 100644
--- a/doc/doc-docbook/spec.xfpt
+++ b/doc/doc-docbook/spec.xfpt
@@ -16828,15 +16828,18 @@ of the other precondition options are common special cases that could in fact
be specified using &%condition%&.

.new
-When originally designed, Exim's ACL system enforced very strict parsing
-of the &%condition%& expansion everywhere it was being processed.
-Through the 4.7x release cycle, the &%condition%& processing while in a
-router became more loose, internally adopting the use of &%bool_lax%&
-instead of the more rigid &%bool%&. This is best illustrated in an
-example:
+Historical note: We have &%condition%& on ACLs and on Routers. Routers
+are far older, and use one set of semantics. ACLs are newer and when
+they were created, the ACL &%condition%& process was given far stricter
+parse semantics. The &%bool{}&% expansion condition uses the same rules as
+ACLs. The &%bool_lax{}%& expansion condition uses the same rules as
+Routers. More pointedly, the &%bool_lax{}%& was written to match the existing
+Router rules processing behavior.
+
+This is best illustrated in an example:
.code
-# This used to fail with a syntax error, now it
-# treats any extra characters as a string
+# If used in an ACL condition will fail with a syntax error, but
+# in a router condition any extra characters are treated as a string

$ exim -be '${if eq {${lc:GOOGLE.com}} {google.com}} {yes} {no}}'
true {yes} {no}}
@@ -16854,10 +16857,16 @@ resulted in the null output (indicating false) with the string
&" {yes} {no}}"& appended to it.

In fact you can put excess forward braces in too. In the router
-&%condition%&, Exim's ACL parser only looks for &"{"& symbols when they
+&%condition%&, Exim's parser only looks for &"{"& symbols when they
mean something, like after a &"$"& or when required as part of a
conditional. But otherwise &"{"& and &"}"& are treated as ordinary
string characters.
+
+Thus, in a Router, the above expansion strings will both always evaluate
+true, as the result of expansion is a non-empty string which doesn't
+match an explicit false value. This can be tricky to debug. By
+contrast, in an ACL either of those strings will always result in an
+expansion error because the result doesn't look sufficiently boolean.
.wen