Roberto -MadBob- Guido wrote:
> On Thu, 2010-01-21 at 13:22 -0500, Jeffrey Stedfast wrote:
>> That won't actually work (at least not very well). The Camel address
>> decoding functions assume their input is supposed to be valid and so
>> it
>> will do whatever it has to do to make it work. It would have to be
>> extremely broken for it to fail.
> Is this behaviour the desired one by design, or it is just broken?

By design. But I suppose you could add some flag or something about
whether or not to be strict in parsing. Sadly, however, there wouldn't
be all that much shared code so it probably wouldn't be worth it.

>> What you'll probably have to do is write similar functionality that is
>> much more strict in what it accepts.
> In the first version of the patch
> ( ) I've
> provided a routine built on regular expressions (regcomp() and
> regexec()). Opinions about that?

A few comments on the patch:

1. it's best not to compare results to TRUE (e.g. don't use "== TRUE"
anywhere. Ever.) because there are a huge number of values for 'true'
(TRUE is defined as ! FALSE).

2. I'm not a fan of regex for these sorts of things (designing a regex
pattern to parse this stuff is typically non-trivial) and I'm pretty
sure that regex pattern is wrong anyway.


Evolution-hackers mailing list

Reply via email to