Live data from Hacker News

PicoC: a very small C interpreter for scripting

code.google.com

11–20 of 47 posts

Re: PicoC: a very small C interpreter for scripting

#12
post #10

Earlier quoted context omitted.

Well, if it's interpreted, the interpreter could sandbox the C code it's running, rather than passing it through directly to its own memory space.

That would kind of defy the whole premise of this thing wouldn't it? The biggest and most sought after "feature" of C is it's speed and direct memory access (and simplicity, I guess). If you take that away, what's left?

Depends on the application, but I could see some mixture of: 1) familiarity; 2) simplicity; and 3) minimal memory usage. Browsing the source code briefly, it really does look like it's an interpreter, with C structs representing Variables, Expressions, and so on.

Re: PicoC: a very small C interpreter for scripting

#15
post #8

I wonder how it compares to other small systems like Lua, or, say Antirez' Jim interpreter, in terms of speed and features.

Hey David, what I think it's cool about picoC is that you can use it in places where you need to script at "hardware" level, like in robotics, embedded systems, and alike.

Otherwise it is probably better to use Lua for instance, since I bet it is much faster (I just read part of the PicoC implementation and it is a pretty straightforward interpreter, very cool to read but hardly the faster) and safer.

Re: PicoC: a very small C interpreter for scripting

#16
I used Ch[1] in a commercial product and I would highly dis-recommend C as a scripting language. Something has to be said for high-level semantics, dynamism and syntax designed for interactive work. I find Lisp, Lua and Groovy to be joy to work with, but C is not an ideal extension/embedded/scripting language. Use something easier.

http://en.wikipedia.org/wiki/Ch_interpreter

Re: PicoC: a very small C interpreter for scripting

#20
post #9
post #7

Earlier quoted context omitted.

Of course it is possible in an interpreter. You simply need to verify each access before allowing it, much like Valgrind does. Of course it's quite costly do to so, and since C gives the programmer a lot of freedom I guess it's hard to optimize the tests, i.e. to know which accesses are safe without explicitly keeping track.

Are you sure? Even Valgrind does not detect everything. E.g. when you mess up variables within your stack.

That's quite different. Sandboxing in an interpreter is actually fairly easy.
Post reply on HN