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.