When creating a bison syntax file that redefines YYSTYPE to another type, bison with the -d flag does not create a *.tab.h file that contains the redefinition present, thus YYSTYPE always defaults to "int" within the *.tab.h file. Yet bison does record the new YYSTYPE type within the *.tab.c file, which then creates a "conflicting type" error when compiled. This error is apparently not new and can be easily found all over google, for instance http://lists.gnu.org/archive/html/bug-bison/2005-06/msg00036.html. Please slap the devs of bison with a large trout. Reproducible: Always Steps to Reproduce: 1. Create a test bison file, test.y, similar to the form %{ #define YYSTYPE double %} ... 2. bison -d -b test test.y 3. compile the resulting test.tab.c file, optionally with a scanner generated by flex. Actual Results: gcc gives a "conflicting type" error. The contents of test.tab.h does not contain the "#define YYSTYPE double" definition but test.tab.c does. Expected Results: test.tab.h and test.tab.c contain similar definitions. Gentoo Base System version 1.6.13 Portage 2.0.51.22-r2 (default-linux/amd64/2005.0, gcc-3.4.4, glibc-2.3.5-r1, 2.6.12-gentoo-r6 x86_64) ================================================================= System uname: 2.6.12-gentoo-r6 x86_64 AMD Athlon(tm) 64 Processor 3400+ dev-lang/python: 2.3.5-r2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-pipe -O3 -march=k8" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-pipe -O3 -march=k8" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X aac alsa avi berkdb bitmap-fonts cdr crypt curl dvd dvdread eds emboss encode esd fam flac foomaticdb fortran gif gnome gpm gstreamer gtk gtk2 imlib ipv6 jpeg libvisual lzw lzw-tiff mp3 mpeg ncurses network nls ogg oggvorbis opengl pam pdflib perl png python quicktime readline samba sdl softmmu speex spell sqlite ssl tcpd theora tiff truetype-fonts type1-fonts usb userlocales vorbis xine xml2 xpm xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
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 :)
