On Friday 13 March 2009 14:09:25 Giacomo A. Catenazzi wrote: > Adrian von Bidder wrote:
[ok, last post from me, this is becoming silly even for -curiosa ;-) We can come back to this topic when we meet next time] > > [1] One obvious way is to parse a whole function on entering it. Given the > > low complexity of plain C code, it can then be executed without allocating > > further memory by just jumping around in the parse tree. > > But this is the problem. C code could be very complex: a lot of nesting > block and hidden variables, a lot of switch cases, very long block and functions, > ... which could require IMHO more memory (thus OOM). Exactly what I'm saying... If the interpreter is written so that it only uses new memory when the compiled C program also would allocate memory (at enter stack frame time or at malloc), there is no difficulty. Yes, the interpreter would hit OOM earlier than the compiled program, but memory allocation failure is legal behaviour for a C program, even if most (malloc() failure) or almost all (stack overflow) programs don't handle it gracefully... cheers -- vbi (... and as for the "eval" construct in interpreters: just handle it like system() in C: call the external interpreter. I guess with a few hacks this might be made to work. Ugliness is not really relevant here. But yes, I see your point. ...) -- featured product: GNU Privacy Guard - http://gnupg.org -- To UNSUBSCRIBE, email to debian-curiosa-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org