> Due to our absurd rule-name-length limitation policy ;), we cannot do the
> sensible thing, which would indeed be:
I don't think it's absurd as long as the language is POSIX, C, or "en".
> MC_{bugnum}_{cmtnum}_{rulename}
I don't think cmtnum is needed if the rule has only been mentioned once,
but I'm okay with always including it if that's much simpler to
implement.
T_{Bnnnn}_{rulename}[_{cmtnum}]
so you'd get:
T_B4012_FOO_BAR
for most cases and:
T_B4012_FOO_BAR_11
sometimes.
> but current naming scheme is:
>
> MC_{rulename}_{rnd}
>
> where {rnd} is a 3-digit random number. (the idea is that hopefully
> the rulename will be short enough to scrape past the length limit,
> since --lint is used to ensure rules are valid before they're checked
> into 70_scraped.cf.)
I definitely want to stick with "T_" for test rules.
> My current plans are to fix this by removing that stupid limit on rulename
> and description lengths. They've caused WAY, *WAAAY* more problems than
> they solved and I'm sick to death of them! >:( Some sensible wrapping
> code would be simpler, and save EVERYONE a lot of trouble.
I don't think wrapping code is a solution at all. Email is
fundamentally 80 columns. Names that go over about a quarter of that
length mean that the descriptions are going to always wrap which is
really gross.
I'd be fine with bumping up the limit by 2 (22+2) for T_ rules since
their final name will be 2 characters shorter. I'd even be okay with
not having any limit on size for test rules. I'm not okay with getting
rid of the length limit at this point.
Daniel
--
Daniel Quinlan
http://www.pathname.com/~quinlan/
