Re: beta testing

[Philippe Bekaert]

Hans,

> I don't really understand what you are doing: With my suggestion, no file
> should include the .tab.h file, only the .tabb.h file does that; instead
> include the .tabb.h file. Then the declaration the macros in the .tab.h
> file will be read singly from any file that includes .tabb.h file, no
> matter thow many times the latter is included.
The wrapper you propose avoids multiple inclusion of the y.tab.h file,
but the duplicate declaration of YYSTYPE is not the result of including
the header file multiple times.

> The .tab file contains
>   #ifndef YYSTYPE
>   # define YYSTYPE int
>   #endif
> which means that you must include the header where you define YYSTYPE
> before you include the .tabb.h file, otherwise it will substitute a default
> definition.
I explicitly tried your suggestion of yesterday now and it didn't work
(I though it would, but that's not the case).

However you redefine and/or declare your own verions of YYSTYPE, you
either end up with
- duplicate declaration of the stack type (YYSTYPE or whatever you
redefine it in)
- a compile error at the point where yyparse() calls yylex(), because
yylex() as I generated it with flex accepts a YYSTYPE* argument and
YYSTYPE is something else at the point where yylex is declared and where
it is called.

Really, I start to believe that the only way to avoid the problem is to
work around the declaration of union { } YYSTYPE that bison always
writes in the y.tab.c file.

> >Why not solve the problem as follows:
> >
> >"If bison is invoked with the -d flag (requesting y.tab.h to be
> >generated), then #include "y.tab.h" in the generated y.tab.c file
> >instead of duplicating the declarations and generate y.tab.h wrapped in
> >proper conditionals avoiding duplicate inclusion."
>
> This statement is so complicated that I cannot follow what you are saying:
Either someone requests bison to generate the y.tab.h file, then why not
#include it in the y.tab.c file (properly wrapped to avoid double
inclusion in case someone like me already includes it on top of
parser.bison)
Or someone does not request bison to generate y.tab.h, and in that case
nothing should change.

> There is no point in including the .tab.h from the .tab.c file, as it is
> not needed -- it's there only so that the lexer can read those macros. Even
> though one can think of including it from the .tab.c file, and excluding
> the macro defined in it on the same time.
I agree that there normally is no point in including y.tab.h in y.tab.c,
because everything that is in y.tab.h is already in y.tab.c, but
including y.tab.h in y.tab.c would be preferable in my opinon over the
current practice of having the same declarations written to both y.tab.c
and y.tab.h.

> The contents of .tab.h file ought to be properly wrapped by conditional
> macros, yes. In addition, I think that some of the things needed from the
> lexer should be written into header, as well.
That's something we definitely agree on.

Philippe.

--
Philippe Bekaert
Post-doctoral Research Fellow
Max-Planck-Institut fuer Informatik
Im Stadtwald, Geb. 46.1
66123 Saarbruecken - Germany
+49 681 9325422 (office phone)
+49 681 9325499 (office fax)
+49 179 4503121 (private phone)