RE: [Fwd: question about error handling]

[Matthew P. Carter 98]

On Fri, 2002-10-04 at 10:49, Tim Van Holder wrote:
> 
> On Fri, 2002-10-04 at 14:33, Latha G wrote:
> > Hi,
> >    I am also struggling with the same problem as 
Ashish. I had gone through 
> > the set of responses for this problem. But still I have 
not got the 
> > solution. Could anybody help me to solve the memory 
leak problem in C?
> 
> > ------- Original Message --------
> > Subject: question about error handling
> > Date: Thu, 07 Jun 2001 11:12:34 -0400
> > From: ashish sehgal <<EMAIL: PROTECTED>>
> > To: <EMAIL: PROTECTED>
> > 
> > HI,
> > 
> > I have the following question about bison:--
> > 
> > When the bison generated parser encounters an error in 
the input
> > expression and there is no error recovery grammar then 
the forrest of
> > linked up structures that may have been created as part 
of parsing need to 
> > be cleaned up else every wrong input stream causes this 
memory to be 
> > allocated and not get deleted at all when the parser is 
working as part of 
> > another thread.
> > 
> > Is there some standard functionality available to do 
some cleanup
> > associated with the values associated with bison's 
internal stack ?? for 
> > instance something that lets you iterate over all the 
values in the stack 
> > and delete them.
> > 
> > thanks for the help
> 
> One common way (not built into bison though), is to keep 
all nodes of a
> parse tree in a list of 'dangling' nodes until they have 
been assigned a
> parent.  This fits in nicely with the bottom-up tree 
construction that
> is natural for a bison-generated grammar.
> After a parse, you can then clean up that list to get rid 
of structures
> that were 'killed' by a (recovered) parse error.

A more efficient approach (also not built into bison) is to 
avoid using std::new or malloc() to allocate your node 
datastructures.  Instead, override operator new or use an 
alternate malloc() to allocate memory from a pool.  Then, 
simply delete that pool when you're done with the node 
datastructures.