Path: utzoo!attcan!uunet!husc6!bloom-beacon!athena.mit.edu!raeburn
From: raeburn@athena.mit.edu (Ken Raeburn)
Newsgroups: comp.lang.c
Subject: Re: "C" Interpreter
Message-ID: <8688@bloom-beacon.MIT.EDU>
Date: 8 Jan 89 14:45:17 GMT
References: <84207@sun.uucp>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: raeburn@athena.mit.edu (Ken Raeburn)
Organization: Massachusetts Institute of Technology
Lines: 80

In article <84207@sun.uucp> haley%lucid@Sun.COM (Mike Haley) writes:
>Iam looking for a "C" interpreter that runs under UNIX.

You could certainly do worse than Saber-C, produced by a company
called (I think) Saber Software, in Cambridge, MA.

I can only say a little bit about the people supporting it.  I know
one of them, Stephen Kaufer, from when he had an office here at
Athena, and I've nothing negative to say about him.  He always showed
interest in any problems I ran into with the software.  (Nice guy,
too.)  I've also dealt a little bit (quick demo in person, or email)
with one or two other people from their staff; they've also been
friendly and responsive.

Saber runs both source and object code, with a reasonably large amount
of sanity checking when interpreting source.  (Uninitialized values,
pointers out of bounds, accessing an object with a type different from
that originally stored there, etc, etc.)  There's also lots of
load-time cross-checking of declarations and definitions.

It also runs in an interactive mode, which interprets shell-like
command lines and C source code, with subroutines available that
implement all of the commands.  (Earlier versions required you to use
C statements for everything, i.e.:

	quit();

	load("foo.c");

but version 2 has a more friendly shell-like interface as well.)

When errors are flagged at runtime, the user can interrupt execution,
run a few commands (examine or modify variables, call other routines)
and resume execution or reset everything and run it over.

The user-settable options include ANSI or pre-ANSI modes (I don't
remember exactly what parameters change here, I always use ANSI);
automatic reloading of changed source files (I think even including
dependencies on header files); miscellaneous parameters about how to
present information to the user; automatic suppression of certain
warnings.

The latest version we've got, at least (dunno about earlier ones), can
handle programs forking; pulls up a new window on your display for the
subprocess, etc.  (Not sure what it does for terminals; I haven't used
this feature much.)

Lots of nice stuff.  I think the only complaint I had about a recent
version (after looking over the documentation) was that there was no
way to turn off its interpretation of lint-style comments like
/*ARGSUSED*/.  At least, I think that was it.  (Sorry, it was a while
ago, and I haven't used it much lately.)

Mmm... make that three complaints.  #2: If you're debugging something
large from source code, it gets to be slow and requires lots of
memory.  Sure, it's to be expected, but I can wish. :-)

And #3: If your program is big enough, and your system runs out of
memory (or you hit your per-process limit), or occasionally with some
other types of errors, saber sometimes finds itself unable to recover.
As I said, I haven't used it in a while, so I don't remember all the
details, and besides, it's probably gotten better since then.

I expect there'll be more and better stuff in future versions.  (Steve
was asking opinions one day along the lines of, "which of these N
features would be most useful to see in the next version of saber?"
They didn't do 'em all, so maybe in the next version. :)

I don't know their street address or phone numbers, but I think Steve
reads this newsgroup; he can probably provide you some more info.

~~
Disclaimer:  I don't work for these folks, I just use there stuff.  I
also don't speak for my employers here, but I think they like the
product too. :)
~~
~~ Ken Raeburn / raeburn@athena.mit.edu
~~ systems programmer
~~ MIT Project Athena
~~