On 2024/10/21 00:34:59 +0200, Kirill A. Korinsky <kirill@korins.ky> wrote:
> On Sun, 20 Oct 2024 16:51:17 +0200,
> Omar Polo <op@omarpolo.com> wrote:
> > 
> > i was thinking something way more complex, but your approach could work
> > as well too.  I'll need a moment to make sure we're not breaking other
> > cases, but I like it.
> >
> 
> Here a bit updated diff where I've adde / into possible string, otherwise it
> won't work with path.
> 
> > > Anyway, keywords is different story, yeah.
> > 
> > this is a pain in other contexts as well, so maybe we could just live
> > with it.  The manpage would need a note that "reserved keywords must be
> > quoted."
> > 
> 
> If I recall right this sort of issue is called shift-reduce conflict and
> %prec is magic which is used to solve it.

unfortunately not.  shift-reduce (or reduce-reduce) conflicts are due to
an ambiguous grammar.  I'm trying to keep smtpd' grammar non ambiguous,
since that has also other interesting properties :-)

The issue here is at a lower level.  The lexer will, say, emit a token
LISTEN whenever it sees "listen" in the input file, regardless of where
we are in the config.  Then, we require { ... } to have only STRING
inside, but the parser doesn't know it, and yacc reports a syntax error
since it has found a, say, LISTEN token instead of a STRING one.

(and afaik we don't have a way to tell yacc to accept any token in a
grammar rule)

I was wandering about adding a flag to control the lexer, but it's too
fragile and also a bit ugly.  Luckily, I think this in practice will not
occur often, and quoting of reserved keywords is already required.  So,
I believe that your idea of parsing "-foo" as a string instead of
erroring could actually work out.  I still have to study the
implications of doing so however.  (ENOTENOUGHTIME unfortunately :-/)