| Summary: | sys-devel/bison-1.875d creates an invalid *.tab.h file when YYSTYPE is redefined | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | postmodern <brodigan> |
| Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | The test bison file | ||
|
Description
postmodern
2005-09-14 17:11:05 UTC
can you post complete examples as attachments to reproduce please ? Created attachment 68482 [details]
The test bison file
The attached file is a test example of bison and redefining YYSTYPE. The test file is a simple postfix calculator which calculates postfix algebra in signed float format instead of the default YYSTYPE of signed int. To compile, test and run the attached file simpley run the following commands. bison -v -d -b test test.y gcc -Wall test.tab.c -o test ./test Then enter various postfix algebraic equations using integers and the operators +, -, *, / and the unary - (which takes the form "NUM n" in this implementation). This postfix calculator example was inspired by (ripped off from) http://dinosaur.compilertools.net/bison/bison_5.html. looks like bison-2.0 handles it just fine ? sys-deve/bison-2.0 does not include the top inlined C code in the *.tab.h file. For the example test.y file this really isn't a problem because it compiles as one .c file. But if I was using flex which had a lex file that needed to include the *.tab.h file to get access to yylval in order to pass tokens up to bison then the problems showup when the design intends that YYSTYPE is not an "int". ok, but flex isnt bison ... so bison-2.0 does 'the right thing' with the example ? bison-2.0 has been in unstable for quite a while without any real issues so i'll prob move it to stable soon also, you could try flex-2.5.31 ... we're planning on moving that to unstable soon The bug is not a product of flex but is exposed by flex. Bison fails to create a
proper header file that accurately represents the choices that the user made in
the design of the bison syntax file, such as various inline C placed in the top
%{ %} block of the bison file (which also include bison related #defines like
YYSTYPE). This problem becomes obvious when a programmer is working with bison
in a project environment that has the code seperated into many source files that
rely on header files for proper definitions. This is what happened to me when I
was trying to redefine YYSTYPE and have my flex generated scanner see the
changes by including the *.tab.h file. You can spot this bug by running the
bison command with the -d flag and checking if the *.tab.h file contains the
inline C at the top of the bison syntax file. I Hope this explains the problem
clearly.
Now that I dig further, bison fails to put anything important in the *.tab.h file. No error codes (YYACCEPT and YYABORT), no function definitions, nothing of use. Please slap the devs with a large trout, using bison in a project is a pain. you could give bison-2.1 a spin but to be honest, you clearly know a lot more about bison than i, so you'd probably have better luck pursuing this on the upstream bison devel list ... Tested 2.1, still no go. I'll close this bug here per your suggestion, and since it's a known issue with some history and I've hand recoded the output of bison in all for my projects. I shall craft some trout laden emails for the bison devs. if you do get some fixes out of them, please keep us updated :) |
