[Caml-list] GCCXML: don't write your own C parser. (WAS: Rewriting UNIX . . .)

["Jeff Henrikson" <jehenrik@yahoo.com>]

> You may be interested in a project I am implementing at the moment:
> The idea is to automatically translate any C program into a
> memory-safe language. . .

You're obviously going to need a parser and I presume you don't want to write one.  Make sure to check out this extenion to GCC
which prints out an XML abstract syntax tree of anything GCC can parse.

http://public.kitware.com/GCC_XML/

Note that this is not _real_ XML, as there is no DTD.  But the file xml.c could be easily hand translated into a recursive set of
variants that would be about 150 lines of caml, along with a simple stream parser could do the task of building the tree.  I'm
going to write such a thing Real Soon Now, as I think it would be especally interestng to do other sorts of C/C++ metalingustic
hacking on account of the vast amount of available code.  (But if you really need it, don't wait for me, as I get busy often)

If anybody reads the GCCXML link and thinks of the most obvious application of stub-code generators for FFI mucking, that's both
why it was written and why I'm playing with GCCXML.  CamlIDL requires too much manual effort; I think the best evidence is
hearing/seeing so many hand written wrappers.  I see no reason for directly handling the raw C code.  I want something like the
SWIG typemap model but cleaner, with an emphasis on not having to edit the original header files.  I went so far as to mostly
implementing a SWIG 1.3.7 module for ocaml, so I see it's strengths and weaknesses.  But SWIG is not probably going to be a correct
or clean program any time soon, so I'd like to clean it up and add some power.  If anybody wants more info I can prodded to write
it down for you.


Jeff Henrikson



-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr