File: README

package info (click to toggle)
c-repl 0.0.20071223-1
  • links: PTS
  • area: main
  • in suites: lenny, squeeze, wheezy
  • size: 80 kB
  • ctags: 31
  • sloc: ruby: 267; sh: 54; ansic: 48; makefile: 42
file content (67 lines) | stat: -rw-r--r-- 2,196 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
Adapted from the author's homepage, <http://neugierig.org/software/c-repl/>:

c-repl
======

Many programming languages come with a REPL (read-eval-print loop), which
allows you to type in code line by line and see what it does. This is quite
useful for prototyping, experimentation, and debugging code.

Other programming languages, and especially C, use a "compile-run" model, and
don't provide a REPL. Let's fix that.

WHAT YOU GET
------------
This approach is actually more of a read-eval loop, as c-repl doesn't know
anything about the types and parse trees of the code it's running. But unlike
other approaches to solving the "C interpreter" problem, c-repl works directly
with unmodified libraries and system headers.

This means you can experiment with a new library without writing a test program
or any bindings. Or just use it as a simple calculator, content in knowing it
is much faster than your neighbors using irb, like driving a Ferarri on city
streets.

EXAMPLE SESSION
---------------
Here's an example session demonstrating using c-repl:

% ./repl
> int x = 3
> int y = 4
> printf("%d\n", x + y);
7
> int mystrlen(char *p) { int i; for (i = 0; *p; i++) p++; return i }
<stdin>: In function 'mystrlen':
<stdin>:5: error: syntax error before '}' token
> int mystrlen(char *p) { int i; for (i = 0; *p; i++) p++; return i; };
> x = mystrlen("hello");
> x
p x
$1 = 5
> x = mystrlen(NULL);
segfault detected.
resuming.
7
> x
p x
$1 = 5

HOW TO USE IT
-------------
Type in any C code you can imagine, and try .help to learn about the
meta-commands (which bring in other system headers or shared libraries).
Please report bugs as you find them!  

HOW IT WORKS
------------

Many of the ideas are due to Satoru Takabayashi, who is responsible for a
prototype implementation and continues to advise.

The approach is surprisingly simple: for each line of code you enter, we
compile a shared object in the background. If the compilation succeeds, the
object is loaded into a child process via dlopen(). If the child process
segfaults, we know that the code was bad and so we can "rewind" by replaying
all n-1 steps. Printing variables is handled by attaching gdb to the child
process.