Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 106016 - sys-devel/bison-1.875d creates an invalid *.tab.h file when YYSTYPE is redefined
Summary: sys-devel/bison-1.875d creates an invalid *.tab.h file when YYSTYPE is redefined
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo's Team for Core System packages
Depends on:
Reported: 2005-09-14 17:11 UTC by postmodern
Modified: 2005-09-28 06:05 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---

The test bison file (test.y,827 bytes, application/octet-stream)
2005-09-14 19:32 UTC, postmodern

Note You need to log in before you can comment on or make changes to this bug.
Description postmodern 2005-09-14 17:11:05 UTC
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
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 file, optionally with a scanner generated by

Actual Results:  
gcc gives a "conflicting type" error. The contents of does not
contain the "#define YYSTYPE double" definition but does.

Expected Results: and contain similar definitions.

Gentoo Base System version 1.6.13
Portage (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/libtool:   1.5.18-r1
virtual/os-headers:  2.6.11-r2
CFLAGS="-pipe -O3 -march=k8"
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"
FEATURES="autoconfig distlocks sandbox sfperms strict"
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"
Comment 1 SpanKY gentoo-dev 2005-09-14 18:46:23 UTC
can you post complete examples as attachments to reproduce please ?
Comment 2 postmodern 2005-09-14 19:32:38 UTC
Created attachment 68482 [details]
The test bison file
Comment 3 postmodern 2005-09-14 19:34:22 UTC
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 -o 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)
Comment 4 SpanKY gentoo-dev 2005-09-14 21:30:01 UTC
looks like bison-2.0 handles it just fine ?
Comment 5 postmodern 2005-09-14 21:53:30 UTC
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".
Comment 6 SpanKY gentoo-dev 2005-09-14 22:24:53 UTC
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
Comment 7 postmodern 2005-09-14 22:55:58 UTC
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
Comment 8 postmodern 2005-09-16 23:08:00 UTC
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.
Comment 9 SpanKY gentoo-dev 2005-09-25 00:34:49 UTC
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 ...
Comment 10 postmodern 2005-09-28 02:35:50 UTC
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.
Comment 11 SpanKY gentoo-dev 2005-09-28 06:05:50 UTC
if you do get some fixes out of them, please keep us updated :)