Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!usc!apple!olivea!mintaka!spdcc!esegue!compilers-sender From: andrea@mprgate.mpr.ca (Jennitta Andrea) Newsgroups: comp.compilers Subject: Question About YACC's Memory Management Keywords: yacc Message-ID: <2371@kiwi.mpr.ca> Date: 11 Oct 90 18:53:34 GMT Sender: compilers-sender@esegue.segue.boston.ma.us Reply-To: andrea@mprgate.mpr.ca (Jennitta Andrea) Organization: Microtel Pacific Research Ltd., Burnaby, B.C., Canada Lines: 33 Approved: compilers@esegue.segue.boston.ma.us I have a parser which is intended to be called repeatedly from a driver program. The driver program extracts a message from the incoming stream, and then calls yacc to parse a single message. Runtime analysis of this program indicates that the data space utilization increases by approximately the size of a message each time the parser is called. Obviously, this is not a Good Thing. I have typed the value stack to contain pointers to characters. I malloc the memory required for each token in lex (assigning yylval to point to that block of memory) before returning the token to yacc. It appears that this memory is not cleaned up when yacc frees the value stack. Am I required to explicitly free each token once the parser has reduced a rule? (I have not seen this done in any of the yacc examples I've looked at) Is there a 'hook' in yacc for me to specify the automatic freeing of programmer-typed tokens when the stack is reduced? Has anyone else out there experienced this problem? (and found a solution!) Jennitta Andrea | Voice : (604) 293-5362 MPR Teltech Ltd. | Fax : (604) 293-5787 8999 Nelson Way, Burnaby, BC | E-Mail: andrea@eric.mpr.ca Canada, V5A 4B5 | eric.mpr.ca!andrea@uunet.uu.net [Neither yacc nor lex does any garbage collection. Either you have to keep track of tokens as you go along, and free them as they're reduced, or else deal with them some other way. I have used an allocator which gets space from malloc in the usual way but chains all the allocated space together. Then after the parser is done, I can zip back up the chain and free it all. -John] -- Send compilers articles to compilers@esegue.segue.boston.ma.us {ima | spdcc | world}!esegue. Meta-mail to compilers-request@esegue.