Related articles |
---|
Passing string literals in function calls in an interpreter jimmyp@hal.csd.auth.gr (2002-12-26) |
Re: Passing string literals in function calls in an interpreter jimbo@radiks.net (2002-12-30) |
Re: Passing string literals in function calls in an interpreter roger@corman.net (2002-12-31) |
From: | jimmyp@hal.csd.auth.gr (Dimitris) |
Newsgroups: | comp.compilers |
Date: | 26 Dec 2002 23:37:53 -0500 |
Organization: | http://groups.google.com/ |
Keywords: | code, practice |
Posted-Date: | 26 Dec 2002 23:37:53 EST |
Hi, I'm writing a simple interpreter and, although it might sound
stupid I'm having a little trouble with passing literal strings in
function calls. The convention used is that of C functions calls(as
the actual functions being called are C functions). The problem is
with where to store the temporary copies of the args. Ints,chars and
floats are no problem as they're kept on the hardware stack, strings
shouldn't be a problem as well since only a pointer to it must be
passed wich is kept on the stack but I don't know where to keep the
actual string in a call like foo("bar");. I'm using bison for the
parser so freeing malloced buffers can be a problem so if anyone has
any ideas on where to find temporary space that is freed automagically
(like space on the stack frame) I'd be very interested.How do
interpreters usually handle calls like foo("bar"); (compilers simply
keep the literal in the binary)?
[You're not the first to run into this problem. If your interpreter
handles a statement at a time, I'd use a wrapped version of malloc
that remembers all the space it allocated in a table or by linking
the areas together, then free it all between statements. GCC and
some other C compilers support a non-standard extension called alloca()
that allocates space in the current routine's call stack, with the
space being returned along with the rest of the local variables
when the routine returns. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.