This is the mail archive of the
gcc@gcc.gnu.org
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: <988954085.24319.ezmlm@gcc.gnu.org>
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,
Tim Josling
> Subject:
> Re: (f)lex & poisoned malloc / free in system.h
> Date:
> Thu, 3 May 2001 22:14:38 -0400 (EDT)
> From:
> "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
> To:
> michael@ximian.com
> CC:
> gcc@gcc.gnu.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.
>