Re: problems with bison-flex

[Laurence Finston]

Sorry, I don't know.  I haven't seen errors like this before.  Would it be 
possible for you to try building your scanner and parser on a GNU/Linux 
system with the most recent version?  It might be worth finding out if 
they build correctly that way.

Otherwise, I can only suggest asking on the address@hidden' list, 
unless someone on this one has an idea.  Flex, of course, has its own 
mailing list or lists.

Laurence Finston

On Wed, 15 Oct 2008, Jim Michaels wrote:

> well, I used C versions of everything like you said to do, and made them .cpp 
> files.
> I have some problems.  bison & flex can't stand themselves.
> 
> 
>     b->yy_is_interactive = file ? (isatty( fileno(file) ) > 0) : 0;
> Error E2015 lex.yy.cpp 5696: Ambiguity between 'std::isatty(int)' and 
> 'isatty(int)' in function yy_init_buffer(yy_buffer_state *,std::FILE *)
> *** 1 errors in Compile ***
> parser.tab.cpp:
> 
> extern "C" {
> #  endif
> #  ifndef YYMALLOC
> #   define YYMALLOC malloc
> #   if (! defined (malloc) && ! defined (YYINCLUDED_STDLIB_H) \
>     && (defined (__STDC__) || defined (__cplusplus)))
> void *malloc (YYSIZE_T); /* INFRINGES ON USER NAME SPACE */
> #   endif
> #  endif
> #  ifndef YYFREE
> #   define YYFREE free
> #   if (! defined (free) && ! defined (YYINCLUDED_STDLIB_H) \
>     && (defined (__STDC__) || defined (__cplusplus)))
> void free (void *); /* INFRINGES ON USER NAME SPACE */
> #   endif
> #  endif
> #  ifdef __cplusplus
> }
> #  endif
> # endif
> #endif /* ! defined (yyoverflow) || YYERROR_VERBOSE */
> Error E2337 parser.tab.cpp 1553: Only one of a set of overloaded functions 
> can be "C"
> Error E2337 parser.tab.cpp 1560: Only one of a set of overloaded functions 
> can be "C"
> 
> #line 68 "parser.y"
>         {free((yyvaluep->strval));};
> Error E2015 parser.y 68: Ambiguity between 'std::free(void *)' and 'free(void 
> *)' in function yydestruct(const char *,int,YYSTYPE *,YYLTYPE *)
> 
>     union yyalloc *yyptr =
>       (union yyalloc *) YYSTACK_ALLOC (YYSTACK_BYTES (yystacksize));
> Error E2015 parser.tab.cpp 4195: Ambiguity between 'std::malloc(unsigned 
> int)' and 'malloc(unsigned int)' in function yyparse()
> 
>       YYSTACK_FREE (yyss1);
> Error E2015 parser.tab.cpp 4203: Ambiguity between 'std::free(void *)' and 
> 'free(void *)' in function yyparse()
> 
> 
> 
> so what do I do about malloc and free?  I really don't need somebody 
> redefining them, they are great just the way they are in the library.  the 
> only time I consistently have problems with programs is when somebody starts 
> messing with these.
> and I need malloc and free.  maybe I should be using new and delete instead, 
> now that I am using C++?
> bison is causing its own problems by messing with malloc and free.
> 
>  
> Jim Michaels
> address@hidden
> http://JesusnJim.com
> 
> 
> 
> 
> ----- Original Message ----
> From: Laurence Finston <address@hidden>
> To: Jim Michaels <address@hidden>
> Sent: Tuesday, October 14, 2008 11:48:31 PM
> Subject: Re: problems with bison-flex
> 
> 
> On Tue, 14 Oct 2008, Jim Michaels wrote:
> 
> > huh? I don't get the context of this. I think you're confusing me
> > with someone else.  no date-time specification. no UNSIGNED_INT,
> > COLON, HYPHEN.  I am working with Autocad DXF group codes.  long,
> > complex scanner with multiple start states (better done custom, then
> > you can do binary format).  long, but relatively simple parser.  
> 
> I was responding to the set of rules you posted, where you said that
> you thought you might have dug yourself into a hole.  I'd have to look
> up exactly what you wrote.  For some reason, I thought it involved
> date-time specifications.  I believe you wrote something about leading
> zeroes.  However, the same principle applies. It is possible to do
> more complex scanning using Flex than is needed when it's used
> together with Bison.  If you are having problems, it might help to
> simplify the scanning rules and keep the complexity in the parser.
> `UNSIGNED_INT',`COLON' and `HYPHEN' were just examples of possible
> tokens taken from my scanner-parser pair. 
> 
> 
> > I have a custom scanner which works in C, but it has not been
> > rewritten for C++ parser interface. 
> > 
> > Borland C++ has a problem in that when it compiles a .c file, it
> > forces ANSI C compilation.  I haven't tried using the -P option,
> > which forces C++ compilation.  Microsoft Visual C++ (MSVC++)
> > operates the same way. 
> > so when I compile a C-only parser generated by bison, my included
> > C++ code suffers with compile errors. 
> 
> I have had a similar problem.  There may be an option,  `-x', perhaps,
> that forces a compilation as a particular kind of file regardless of
> the suffix.  However, the simplest solution, and the one I use, is just to
> use the `-o' option to Bison so the output file has the appropriate suffix.
> 
> Laurence Finston
> 
> 
> 
>       
> _______________________________________________
> address@hidden http://lists.gnu.org/mailman/listinfo/help-bison
>