Re: yyparse being prototyped in y.tab.h causes problems.

[Kaz Kylheku]

On 19.08.2015 11:26, Akim Demaille wrote:
> > Le 19 août 2015 à 15:38, Kaz Kylheku <address@hidden> a écrit :
> >
> > On 18.08.2015 23:24, Akim Demaille wrote:
> > > As you reported, the standard does not even report YYSTYPE,
> > > which is clearly needed.
> >
> > Reported to Austin group yesterday;
> >
> > http://austingroupbugs.net/view.php?id=977
>
> Your example seems to be about a pure parser, where yystype is given
> as argument.  I think it should rather be about yylval.

I will fix it. The traditional lexer is of course int yylex(void),
and the current stack item is a global. The lexer needs it declared,
but doesn't need to know its type, as far as I remember.

> > > > Anything that is broken doesn't address needs.
> > > :)  I agree.  But I guess our opinions diverge on the definition
> > > of brokenness.
> >
> > I'm going by "fails to compile".
>
> Sure.  But you didn't answer to my final remarks:
>
> > But really, what's wrong with adding
> >
> >  typedef struct parser_context parser_context;
> >
> > in your parser.h before the #include "y.tab.h"?  There is
> > no need for this mutual inclusion.

What is wrong is approximately the same kind of thing
that would be wrong if, say

  #include <stdio.h>

suddenly complained that "ptrdiff_t" doesn't exist,
and the Glibc maintainers told everyone "there is
no real problem, just include <stddef.h> before
<stdio.h> when using our library."

You've changed the interface %pure-parser such that
some code which previously built cleanly has to be
modified.

(Where is that documented, even?)

You don't seem to understand that you can't go around
changing tools and then just tell people to update
their code with workarounds, even if those workarounds
are simple.

In my project, I have a rule that headers don't include
headers, so .c files have:

  #include "y.tab.h"
  #include "parser.h"

How all files including y.tab.h would have to have:

  struct parser;
  struct scanner;
  #include "y.tab.h"
  #include "parser.h"

I (justifiably) don't like such loose declarations
being repeated; which is why I would have
#include "parser_forwards.h" in their place.

Scrubbing y.tab.h is cleaner though; the workaround
is confined to a couple of lines of the Makefile.

I can only expect more breakage from Bison in the future,
and the most general strategy for dealing with it is to
process its output. The "module" for dealing with that
will nicely be confined to one place in the Makefile
instead of spreading through the program sources.

If the tumor is operable, why apply chemotherapy?