🚀 go-pugleaf

In article <846896475snx@warren.demon.co.uk>
           leveret@warren.demon.co.uk "Nick Leverton" writes:

[ apologies for quoting in full - difficult to trim.. ] 

> Ok, here's an obscure one for y'all ...
> 
> I put a line in my NNTP killfile as follows:
>     Subject: *[ _-]LOOT[ _-]*rail*
> wanting to catch "lootrail", "loot-rail", "loot_rail" and "loot rail"
> and similar combinations (if you read misc.transport.urban-transit
> you'll understand).
> 
> But it also catches a whole lot more.  Setting nntp trace to 3 shows
> me that it also kills stuff like:
> 
>     Subject: Re: Poly marriage contract
>     Subject: Re: More Junk Email
>     Subject: Re: "Name of a dog! Rover
> 
> Looking at the code for wildmat(), I guess it is getting confused about
> the hyphen and imagining it is part of a character range.  A hyphen as
> first or last in the string ought to be treated as a literal, but
> wildmat doesn't conform to this convention.
> 
> The line in wildmat.c, case '[', that says
> 
>     if(*p == '-' ? *s <= *++p && *s >= last : *s == *p)
>         matched = TRUE;
> 
> is the one in error.  I was going to suggest a correction but I'm having
> trouble in coming up with one as efficient as KA9Q standard !  It's not
> too hard, obviously, to do by brute force of code, but I'd like to keep
> the memory requirements down in any fix ...

You're right of course - wildmat as written here doesn't make
any allowance for '-' being a valid member of the [..] set, but
only as a range specifier.  Here's the best I can manage:
    ...
    for (last = 0400, matched = FALSE; *++p && *p != ']'; last = *p) {
#if ORIGINAL_VERSION
        /* This next line requires a good C compiler. */
        if(*p == '-' ? *s <= *++p && *s >= last : *s == *p)
            matched = TRUE;
#else
        if (!matched)   /* don't unset a previous match */
        {
            if (*p == '-' && last != 0400 && p[1] != ']')
            {
                matched = (*s <= *++p && *s >= last);
                continue;
            }

            matched = (*s == *p);
        }
#endif
    }
    ...

This occupies an extra 16 bytes compared with the original 
(albeit a small model comparison) but even doubling that should
not cause undue grief to ka9q/textwin. And if one's setup is
*that* marginal, there's always the option decrementing a FILES
or BUFFERS setting (or even lobbing a couple of paragraphs off
the environment space).

But to return to your original problem, how about:

     Subject: *LOOT*rail*               (or *LOOTrail* )
     Subject: *LOOT?rail*

This is still not exactly what you're after, but probably
better than your "correct" entry with broken 'wildmat' :)
-- 
Pete