I recently thought about writing an interpreter for C, probably in C. Do you know of any similar projects?
My idea was that the interpreter would be able to perfectly simulate the C standard, notice any undefined/implementation-defined behavior and simulate different compilers. This would allow simple debugging/visualization. You can also easily track memory, recognize memory leaks, recognize out of bounds error, etc...
Posted Jun 24, 2020, 4:27 PM UTC
You may want to look at:
https://github.com/root-project/cling
Cling is an interactive C++ interpreter, built on top of Clang and LLVM compiler infrastructure. Cling realizes the read-eval-print loop (REPL) concept, in order to leverage rapid application development. Implemented as a small extension to LLVM and Clang, the interpreter reuses their strengths such as the praised concise and expressive compiler diagnostics.
I tried it once and it seemed to work fine.
Well, it isn't really an interpreter, but a REPL on top of an JIT-compiler (at least in my understanding). My idea is a complete interpreter that is on a abstraction level well above assembler or llvm, so on top of calling conventions as example.
Here are some that I have looked at over the years. These are all C subsets, not full C.
I particularly like C4 (small enough to grasp, and self-compiles) Pico C (much larger subset of C) and UnderC (interprets some C++ too).
C - extended C4 by the same author
Little C - from Herb Schildts C books
[deleted]
I think you basically want https://github.com/rust-lang/miri but for c
Yes!
even though I know that such a tool would be incredibly useful. I think the C/C++ community still live under the "CaUsInG UnDeFiNeD BeHaViOr Is FoR PeOpLe ThAt DoNt KnOw HoW To Code" motto.
On the other hand you'll have to figure out how to make an interface between gcc/clang and your interpreter so you're able to reuse most of the frontend. There is a link to a PDF about the miri design so you can get some inspiration from there.
you may be interested in haybale: https://github.com/plsyssec/haybale
Also I believe you can already use wasm as a C interpreter if you were so inclined.
I once wrote PicoC for many of the same reasons you're talking about.
PicoC is cool! I have used the repl for testing expressions, especially bit-wise operators. Thanks for writing PicoC, and making it available!
You're welcome. It was a fun project.
I stumbled across tcc, but it still is a compiler. It compiles the script, but doesn't do actual interpretation of the source code. I imagine a system where memory is tracked permanently.
Tcc does that.
Tcc has memory/bounds-checking and sanitization.
tcc --help
Haven't even thought somebody might want an interpreter for C.
Did you try to search with your question? I found several projects that implement interpreters for C language.
I tried, but didn't find any. I only found interpreters written in C (obviously). What did you use as search terms?
How about HolyC?
Well, I found the SO question. But that is more about a REPL, and the interpreters are often extended with high-level features, not with the focus of debugging correctness.
I had a go at it once, and (IIRC) got to where I could run very simple programs, but I found it hard to see the point of it so dropped it.
Tricky issues I found included calling external binaries. In particular the C runtime in MSVCRT.DLL. If C source for the runtime functions can be found, that could be interpreted too. But the wider problem of calling existing binary code remains.
An associated one, but more tricky, was callback functions, where you pass a function pointer to an external library, then it calls that function. Now, binary code can't directly call interpreted code; you need to arrange something in between.
But then, out of the 1000s function pointers used in a program, how many will be called solely from interpreted code, and how many from outside?
You get similar problems with any interpreted language, but there at least there is a clear line between the interpreted language, and that of the external library.
C interpreters exist, so either they are limited in some way, or a lot of work has gone into solving such problems.