[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bison 2.1 generated code always returns error
From: |
Joel E. Denny |
Subject: |
Re: bison 2.1 generated code always returns error |
Date: |
Sun, 5 Oct 2008 14:22:44 -0400 (EDT) |
On Sat, 4 Oct 2008, Jim Michaels wrote:
> bison 2.1 generated code always returns an error: 1.
> parse failed: invalid input.
> this is always on the last token at end of file where it matches "EOF"
> (T_EOF).
> it does the same thing whether I return 0 if I find the token instead of
> returning T_EOF from the lexer (flex), or if I just return T_EOF and let the
> flex lexer do its own end-of-file handling.
>
> something is wrong. bug in 2.1?
> an update to 2.3 is unavailable in the gnuwin32 project.
I don't recall ever encountering such a bug in 2.1, but 2.1 is 3 years
old, and I've never used gnuwin32. If you only use windows, I recommend
you try your example with Bison 2.3 in Cygwin.
> also, how can I configure bison so it uses "lalr1.cc" without getting these
> errors:
> C:/gnuwin32/GETGNU~1/gnuwin32/share/bison/lalr1.cc:22: m4: Cannot open
> c:/progra~1/Bison/share/bison/c++.m4: No such file or directory
>
> bison happens to be installed in a different directory than c:\program
> files\bison
> it is installed in C:/gnuwin32/GETGNU~1/gnuwin32/bin
I don't recall that bug in 2.1 either. To work-around it, you might try
setting the env var BISON_PKGDATADIR to the correct directory containing
the installed skeleton files. This should override Bison's configured
directory. If that doesn't work, perhaps you can manually edit lalr1.cc
to reference the correct file.
For this latter bug, my guess is that the gnuwin32 build of Bison is
broken. If you can't work around the problems, you might want to contact
the gnuwin32 maintainers.