Re: [nft PATCH 2/2] scanner: Extend asteriskstring definition

[Phil Sutter <phil@nwl.cc>]

Hi Pablo,

On Fri, Feb 07, 2020 at 06:31:40PM +0100, Pablo Neira Ayuso wrote:
> On Thu, Feb 06, 2020 at 12:38:28PM +0100, Phil Sutter wrote:
> > Accept sole escaped asterisks as well as unescaped asterisks if
> > surrounded by strings. The latter is merely cosmetic, but literal
> > asterisk will help when translating from iptables where asterisk has no
> > special meaning.
> > 
> > Signed-off-by: Phil Sutter <phil@nwl.cc>
> > ---
> >  src/scanner.l | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/src/scanner.l b/src/scanner.l
> > index 99ee83559d2eb..da9bacee23eb5 100644
> > --- a/src/scanner.l
> > +++ b/src/scanner.l
> > @@ -120,7 +120,7 @@ numberstring	({decstring}|{hexstring})
> >  letter		[a-zA-Z]
> >  string		({letter}|[_.])({letter}|{digit}|[/\-_\.])*
> >  quotedstring	\"[^"]*\"
> > -asteriskstring	({string}\*|{string}\\\*)
> > +asteriskstring	({string}\*|{string}\\\*|\\\*|{string}\*{string})
> 
> Probably this:
> 
>         {string}\\\*{string})
> 
> instead of:
> 
>         {string}\*{string})
> 
> ?
> 
> The escaping makes it probably clear that there is no support for
> infix wildcard matching?

Ah, you're right. I assumed it wasn't necessary to escape the asterisk
mid-string, but if we ever added support for infix wildcards (no matter
how unlikely) we were in real trouble.

BTW: Given how confusing bison-generated error messages are, maybe I
should introduce "infixasteriskstring" in scanner.l to catch unescaped
infix asterisks and generate a readable error message from there?

> This asteriskstring rule is falling under the string rule in bison.
> This is allowing to use \\\* for log messages too, and elsewhere.

Ah, that's right. Good, bad, ugly? Just a "neutral remark" from you? :)

Thanks, Phil