This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: (f)lex & poisoned malloc / free in system.h


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.
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]