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. _______________________________________________ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
