Hello!
On Fri, 18 Oct 2002, Nico Erfurth wrote:
> Alexander V Alekseev wrote:
>
> >>> Every bug is usefull. It's very simple to invent example of
> >>> usefullness of any trouble. But it will stay a bug.
> >>
> >> Man, this isn't a bug, this is just a "we don't care about".
> >
> > Hmmm... So, why don't "we don't care about" after applying my patch?
> > ;-))
>
> Because it will BREAK configurations, why do YOU not just use escaping,
> like anyone else would do in such a situation? I do escape } and { if i
BTW, if you always escape your {} , you needn't worry about.
> need them in between and i did it because it was logical.
Really, I don't know exim's language good enough to give you
example just from docs, but the trouble occur, if you have construct
like this: operation1{operation2{something}} and need first to
expand operation1 using "operation2{something}" as argument, and only
after that you need to expand "operation2{something}" into new string.
I think, you can invent current example yourself.
But I can explain, why I need this feature: I tried to speedup
lookup process to any lookup type you want. How can we do it? The only
way of doing it (without modifying all lookup types) is to wrap
cashed lookups in a new lookup types. For example, if you have (just
from spec.txt):
################################################
data = ${lookup mysql{ALIAS_QUERY}}
################################################
so I rewrite it as follows:
################################################
data = ${lookup sharedcashe {lookup mysql{ALIAS_QUERY}} }
################################################
and we first look in cashe, using string "lookup mysql{ALIAS_QUERY}}" as
key, and if nothing found, add '${' before and '}' after the lookup
key, and expand the string once more.
If you always escape your {} , nothing bad will happen. But it's
too ugly to change {} to anything alse in case shown.
> Please show me an example where the current behaviour causes trouble.
>
> >>> 1. All examples in spec.txt have balanced {}.
> >>
> >> Sure, but this is the usual behaviour "escape a char if it could
> >> cause trouble", again, we are NOT talking about C/Perl/XXX.
> >
> > There are no words about "escape a char if it could cause trouble"!
>
> Yes, sometimes one should THINK! ;)
But there is no idea in documentation, that unescaped {} should
sometimes work! They should never work, or be clearly documented!
> > The documentation seemed to me as a definite set of syntaxis and
> > semantics rules. All constructs, that can be built according to
> > documentation, should work. Now I see, it's wrong. You mean, I should
> > read specs.txt as a list of ideas, how it "should, but may not" work.
> > You mean, that users of MTA (as you pointed out, exim is MTA, not
> > C/Perl/fuzzy logic interpreter/self-debugger) should read sources and
> > possibly debug exim, to understand why constructs do not work? A
> In fact, i'm reading this list since some years, and i NEVER saw someone
> complaining about it, i think until now anyone was clueful enough to
> just escape the }.
You're right. Everyone escapes them. So, what do you worry about?
> > which affects all syntaxis constructs used by exim. It should be
> > definitely documented, or fixed.
>
> The exim-parser is meant to be FAST, not to be a complete scripting
> solution, i think Philip would have used Yacc or Bison if he wanted
> something like this.
I just add 1 integer compare per '}' found. And 1 integer "++"/"--"
operation per '{' or '}' found. Do you think it'll slow down parce
process? (May be you have millions of '{' or '}' in your config, but I
can't imagine it.)
BTW, I did that just to speedup overal speed. (Though
exim's speed is quite discussible. On my P4 1.8 / 256M I see only
about 100 messages per second enqueued, and about 30 messaged per second
relayed. On such configuration, CGP enqueues more 1000 messages per second,
and relays about 300. ;-(( I used default config, supplied with exim,
but changed all lookup to MYSQL. Using default lsearch fails to
extremely low speed. The main trouble is fork(), and reinitialisation.
But I don't think, it's really possibly to make exim threaded in a
moderate period of time. )
> >>> 3. Can you exactly document exim's behaviour now? Especially, if
> >>> lookup requests return something with {} ? Or using lookup in
> >>> conditional expressions? I suppose, now exim's behaviour is
> >>> completely unpredictable. It's undocumented. It's a BUG.
> >>
> >> It will not be better with your patch, think about it twice. You
> >> are just thinking about balancing brackets, but they don't need to
> >> be balanced, if they are escaped.
> >
> > I've thinked about it many times. It's really difficult to
> > create/understand/debug sentences with unbalanced {}. Just as an
> > idea: if it is really usefull, why perl developers (who broke many
> > commonly adopted programming language constructs) don't use
> > unbalanced {} ?
>
> See my last comment.
>
> > Please, think yourself. Is it really easier for you to undestand and
> > create unbalanced constructs? Especially, the way exim is handling
> > them? You have to predict, how many '}' you should supply to your new
> > construct!
>
> Hu?
> Why should i need to predict them?
> I just escape } and { if they are located in a string.
> And you don't need balanced constructs all the time, don't you
> understand this? a } could be without any { in a string, what you do, is
> BREAKING this, you break something that isn't wrong at all.
You pointed out, that everyone escapes {}. That's right. Why do
you think then, such undocumented bug should be supported? For someone,
who don't read the documentation?
Bye. Alex.
