Re: ILU for VHLL FFI [was: RFD: Programming Language Feature Matrix]

In article <LTH.96Jan17095953@blackrabbit.cs.uoregon.edu> lth@blackrabbit.cs.uoregon.edu (Lars Thomas Hansen) writes:
 > There is already a system which does this for C++ and which targets
 > Aubrey Jaffer's scm, by compiling the C++ definitions into
 > scm-compatible C++ code which can then be linked into the interpreter;
 > see
 > 	http://www-white.media.mit.edu/~kbrussel/Header2Scheme
 > However, Larry's (Dylan's) solution is much nicer, and I've been
 > planning something similar for some time, only slightly more reusable.
 > The basic idea is to provide a program which takes C header files (C++
 > is probably a must at some point but a truly daunting task) and produces
 > an easily machine-readable and -parsable intermediate form
 > (s-expressions, say) which can then be converted to the quirks of an FFI
 > for whatever Scheme system you're using (or to ILU ISL, for that matter)
 > using a ``code generator'' written specifically for the task.  Many of
 > the code generators will probably be similar in structure, so one can
 > expect some reasonable amount of sharing of labor even here.
 > The current plan is to attempt to use the lcc front end for this
 > project, although I have not looked at the code carefully enough to
 > _know_ that it will be straightforward.

Another possible codebase to draw from is the LCLint toolset:


LCLint is a lint-like tool for ANSI C. It can be used like a traditional lint to detect
certain classes of C errors statically; if formal specifications are also supplied, it
can do more powerful checking to detect inconsistencies between
specifications and code. 

Without specifications, LCLint does many of the checks done by a traditional lint.
It reports unused declarations, type inconsistencies, use-before-definition,
unreachable code, ignored return values, execution paths with no return, likely
infinite loops, and fall-through cases. It provides options for stricter type-checking
than standard C (e.g., char and bool types can be treated as distinct from ints.).
It does not do much of the portability checking (e.g., pointer alignment) done
by typical lints. 


I haven't looked at the code, but it compiled and ran "out of the box" when
I was using it.

It has at least one novel feature: it groks macros. It doesn't lose
information in the pre-processing stage.

Daniel W. Connolly        "We believe in the interconnectedness of all things"
Research Scientist, MIT/W3C     PGP: EDF8 A8E4 F3BB 0F3C  FD1B 7BE0 716C FF21 
<connolly@w3.org>                  http://www.w3.org/pub/WWW/People/Connolly/