After doing so, evaluate #1$rme_test_constant, and you'll get 45, as you'd expect. (Continue from the cerror whining about making a constant unbound, if needed.). The argument of 1 forces the cdb file on disk to be consulted, rather than just re-using a possibly already-defined defconstant form.
Now, change the .ffi file (in ccl:darwin-x86-headers64;foo;C;foo.ffi, presuming you're on an x86-64 Mac) to read as follows:
Do (parse-standard-ffi-files :foo) again. This time, you'll observe that evaluating #1$rme_test_constant will signal an error "foreign variable not found". Perhaps parse-ffi chokes when the type in a cast is a macro?
Consider this fragment of a
.ffi
file (as produced by the interface translator):If you put this in, say,
ccl:darwin-x86-headers64;foo;C;foo.ffi
, you can process it from lisp like so:After doing so, evaluate
#1$rme_test_constant
, and you'll get45
, as you'd expect. (Continue from the cerror whining about making a constant unbound, if needed.). The argument of 1 forces the cdb file on disk to be consulted, rather than just re-using a possibly already-defined defconstant form.Now, change the
.ffi
file (inccl:darwin-x86-headers64;foo;C;foo.ffi
, presuming you're on an x86-64 Mac) to read as follows:Do
(parse-standard-ffi-files :foo)
again. This time, you'll observe that evaluating#1$rme_test_constant
will signal an error "foreign variable not found". Perhaps parse-ffi chokes when the type in a cast is a macro?Uncommenting the lines in eval-c-expression https://github.com/Clozure/ccl/blob/f9650bc09dbb80d99434f0ad1145b3020427fbb7/library/parse-ffi.lisp#L371-L372 will show that something is getting indigestion.
This comes up in real life as the following snippet from the MINGW64 winsock2.h header file: