Re: bison and valgrind
- From: "Rob Thorpe" <rthorpe@xxxxxxxxxxxxxxxxx>
- Date: 29 Mar 2007 08:11:20 -0700
On Mar 29, 10:31 am, "Chris Uppal" <chris.up...@xxxxxxxxxxxxxxxxxxx
THIS.org> wrote:
Rob Thorpe wrote:
The normal way of using bison is to use it to produce a parse tree.
You write code in the actions that builds up a tree out of nodes, you
only need one or two different types of node. In the actions all that
happens is memory allocation. Then the parser completes and passes
the parse-tree to the next compiler pass. Cleanup is only done after
the parser has completed.
Worth checking what happens if the parser detects a syntax error. I
suspect that the parser (i.e. the Bison input) should probably have
semantic cleanup actions for such errors, or temporary data allocated
before the error was detected may be leaked. (NB: I haven't tested
that, it's just a guess based on my memory of Yacc from years gone by).
In a normal parser for a programming language that does not matter.
Since the parser has detected an error it will exist without
generating code, and do little further allocation. The OS can deal
with cleanup.
If it is a problem such as in a persistant program than there are
other tactics. As Chris D said the parsing can be done twice.
Another method is to issue the error then wipe the temporary data,
possibly the whole parse tree, this could prevent useful error
handling though. The most sophisticated solution, apart from GC, is
the one you mention to insert code into the path that results from
bison errors that cleans up any possible allocation problems.
.
- References:
- bison and valgrind
- From: Allan Adler
- Re: bison and valgrind
- From: Rob Thorpe
- Re: bison and valgrind
- From: Chris Uppal
- bison and valgrind
- Prev by Date: iTechArt Group - Custom Software Development and Offshore outsourcing Company
- Next by Date: Re: bison and valgrind
- Previous by thread: Re: bison and valgrind
- Next by thread: Re: bison and valgrind
- Index(es):
Relevant Pages
|