This is the mail archive of the
mailing list for the GCC project.
Re: (f)lex & poisoned malloc / free in system.h
- To: gcc at gcc dot gnu dot org
- Subject: Re: (f)lex & poisoned malloc / free in system.h
- From: Tim Josling <tej at melbpc dot org dot au>
- Date: Sat, 05 May 2001 05:26:07 +1000
- Organization: Melbourne PC User Group
- References: <email@example.com>
I am working on a COBOL front end to GCC. I did not have this
problem because I define my own YYSTYPE. Maybe you could manually
define YYSTYPE and thus avoid including the problematic headers.
Another approach could be to redefine malloc and free as
my_malloc and my_free - and have these functions in another
module, that just call the original malloc,
> Re: (f)lex & poisoned malloc / free in system.h
> Thu, 3 May 2001 22:14:38 -0400 (EDT)
> "Kaveh R. Ghazi" <firstname.lastname@example.org>
> > Since (f)lex generates malloc / free in its autogenerated
> > code, and since mostly generated lexers include the parser's generated
> > header, which in turn includes the YYSTYPE union, which in turn will
> > inevitably require headers that require system.h - how can one use
> > (f)lex to generate a lexer for a gcc language frontend in gcc 3 ?
> > Of course, I'm lead to believe that only the slow of thinking
> > like to use generated lexers - and this seems to be born out by a lack
> > of .l's lying in the gcc source tree.
> > Naturaly I'm almost certainly missing a trivial, portable way
> > to override the autogenerated malloc / free, but I can't find one
> > lurking in the man pages.
> > Any thoughts ?
> > Michael Meeks.