Re: problems with bison-flex

[Jim Michaels]

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