|Main Archive Page > Month Archives > spamassassin-dev archives|
--- Comment #6 from Adam Katz <firstname.lastname@example.org> 2011-09-10 00:31:25 UTC ---
I like the documentation changes, but I think "missing or invalid delimiters"
was better than the new phrasing,
lint: config: SpamAssassin failed to parse line, "__HAS_REFERENCES_ADDR
exists:References:addr" does not specify a valid header field name for
"header", skipping: header __HAS_REFERENCES_ADDR exists:References:addr
at build/mkrules line 254.
$value and $line are nearly identical and therefore redundant.
Maybe something like:
$parse_error = "config: SpamAssassin failed to parse line, \"$def\" ".
"does not specify a valid field name for \"$key\", ".
Another note: even though this fails t/lint.t (but only on the first run since
a 'make clean' or rules update), 'make test' does not fail and 'spamassassin
--lint' still has no output (and -D doesn't add anything on this front). Are
these the desired outcomes?
Separately, and I know this was in the code before Mark touched it, I dislike
our use of the regex character class [!-9;-\176] which matches the two
ranges from "!" to "9" and from ";" to "\176" (~, tilde). I had to look at a
character map to even figure out that this is really just looking for any
non-colon/non-space/non-extended printable characters (basically [^:\s]
though I think other code has already handled the white space). (An extra
level of confusion: POSIX regexps that begin with an exclamation point are
negated.) Do we really need to look for extended or non-printing characters
here? Can we instead simplify this to [^:] or [^:\s] ?
-- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.