Re: Reclaiming dynamic memory if parse fails?

Chris Dollin <chris.dollin@hp.com>
Mon, 16 Jul 2007 09:13:41 +0100

          From comp.compilers

Related articles
Reclaiming dynamic memory if parse fails? carsonbj@gmail.com (carsonbj@gmail.com) (2007-07-13)
Re: Reclaiming dynamic memory if parse fails? chris.dollin@hp.com (Chris Dollin) (2007-07-16)
Re: Reclaiming dynamic memory if parse fails? DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-07-16)
Re: Reclaiming dynamic memory if parse fails? kenshin_40@htomail.com (Mark Holland) (2007-07-16)
Re: Reclaiming dynamic memory if parse fails? martin@gkc.org.uk (Martin Ward) (2007-07-16)
Re: Reclaiming dynamic memory if parse fails? blume@hanabi.local (Matthias Blume) (2007-07-18)
| List of all articles for this month |

From: Chris Dollin <chris.dollin@hp.com>
Newsgroups: comp.compilers
Date: Mon, 16 Jul 2007 09:13:41 +0100
Organization: HP labs, Bristol
References: 07-07-051
Keywords: parse, errors
Posted-Date: 18 Jul 2007 20:02:10 EDT

carsonbj@gmail.com wrote:


> I'm using lex and yacc for parsing a configuration file that builds a
> dynamically allocated tree structure for runtime searching as user
> requests come in. When a parse fails, in the middle of the
> configuration file, and the tree is partially built, how can I reclaim
> all of the dynamic memory gracefully? The tree is built from the
> bottom up, the references to the pointers of the tree are passed
> between each of the grammar rules using the $$ = (some pointer)
> scheme, finally the root of the tree is set at the start symbol.
>
> I thought of having a global array of some structure holding a pointer
> to each dynamically allocated structure and an enum to identify the
> type of the object. Then as each item is allocated, it is added to
> the array. Then if yyerror is called, it could free all of the
> references in that list. This method seems clumsy to me though...
> Any other ideas?
>
> Thanks.
> [There's no really clean way to do it. Allocating out of a fixed
> arena is one popular approach. I've used a wrapped version of malloc
> that chains all the allocated chunks together, then run down the chain
> and free them all when it's done. -John]


One thing we did once, if the context fits, is this -- first parse the
input with store allocation /switched off/. If it fails, you're
done. If it succeeds, parse it /again/, with allocation on. You know
it won't fail in the middle (well, not with a parse error anyway).


Obviously it only works if you can reliably read the input twice
and have control over the parser's store-allocation code, and is
only sensible if the input doesn't take that long to parse.


The other thing I /think/ I've done is the natural hybrid of John's
two tactics -- node-allocate out of an allocated Big Zone, and when
the Big Zone runs out, allocate another Big Zone. Keep track of all
the Big Zones and deallocate /them/ when you're done. Now you've
decoupled the free-me overheads from the structure of the tree nodes.


--
Chris "assuming that's not what John meant by his last sentence" Dollin


Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.