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 [EMAIL PROTECTED]' 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
> [EMAIL PROTECTED]
> http://JesusnJim.com
>
>
>
>
> ----- Original Message ----
> From: Laurence Finston <[EMAIL PROTECTED]>
> To: Jim Michaels <[EMAIL PROTECTED]>
> 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
>
>
>
>
> _______________________________________________
> help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
>
_______________________________________________
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
