The LJIT2libc project represents a fair body of ffi.cdef[[]] stuff. For the
most part, libc is fairly well behaved in terms of the C definitions, but it
does run the gamut including various attributes (packed), decorations
(__restrict, exterm), bitfields, and other oddities.
As such, I think it's a good test case for the ffi interfaces. It's not
rigorous, as it does not run through all the positives, negatives, and breaking
changes, but it does represent a real world corpus of commonly used ffi calls.
proposal: This is one test case that should be added to the mega test case
system when it is developed.
Also, there was a suggestion that the mega test case system be a separate
project from the core compiler. I think that's probably a good idea as well.
You might have different governance for the test case project than the core
compiler. The way I see it is, there are probably two different sets of tests.
One is a basic compilation/breaking changes sort of thing, that can be run in
a fairly short time, per checkin to quickly confirm whether things are
breaking, conformant, relatively performant, etc. Then there's this mega
project test system which can include a ton more interesting stuff both ad hoc
and structured which act as the "smoke test". These can run at any time, but
are not required for a basic checkin. Probably run more as a conformance suite
before a release, or periodically just to keep things sane.
The LJIT2libc would live in this latter system, not in the core 'in-project'
test cases.
As an aside, going along with the suggestion of being able to reimplement
something (SQlite was used as the example), you could probably use LJIT2libc to
help such a task. You can basically write what looks fairly close to the C
implementation of something, but from within the context of luajit.
-- William
===============================
- Shaping clay is easier than digging it out of the ground.
