CFFI govels size_t into :sizet [Was: cffi 0.17.0 breaks some stuff]

[Stelian Ionescu]

> > Do you think that the osicat maintainer would be willing to
> > "contribute" the stdlib definitions to the proposed new system?
> 
> well, i always forget about osicat, but osicat itself *is* supposed to
> be that system i was pondering about, except that it's also kinda
> posixly confused...
> 
> (in-package #:osicat-posix)
> 
> (ctype size "size_t")
> (ctype ssize "ssize_t")
> 
> there should be a system for C stdlib.h, stddef.h, etc stuff, which
> has nothing to do with the underlying OS. of course this system will
> require groveling and thus on windows it will be a pain to use, but
> what isn't a pain on windows...?
> 
> i'll look into setting up the skeleton of such a new CFFI system. my
> proposed name is CFFI/STDLIB, both for the asdf system and for its
> package, but suggestions are welcome.
> 
> details on the header files:
> 
> https://en.wikipedia.org/wiki/C_standard_library#Header_files

I've often thought of doing something like this, especially since given a platform, the ABI is well-known. The hard part is determining the platform of the host Lisp, i.e. http://wiki.osdev.org/Target_Triplet.
If we can determine that, we could have a system consisting of hard-coded values, one platform per file, and have CFFI load that at runtime. It could replace not only the grovelling done in Osicat and IOlib for POSIX types, but also the use of the host FFI's variable-sized C types, e.g. instead of CFFI's :long -> sb-alien:long, we'd have :long -> :int32 -> host 32bit signed integer.

Of course, we can add a hard compile-time dependency on gcc/clang and run cc -dumpmachine in a macro. I would totally do this, some users might not like it though. OTOH, it would be a quick hack that works 100% and can only be improved in the future.

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.