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.
And this hard-coded file would not have to be generated manually. It can be generated by c2ffi or a similar dedicated program(but for bootstrapping reasons it should probably written in C++), and every time somebody gets an error that their host platform is not supported, tell them to compile and run that program and send us the resulting file to include in the repository. We can easily take care ourselves of x86-pc-linux-gnu, x86_64-pc-linux-gnu, x86_64-pc-freebsd10, x86_64-apple-darwin and x86_64-pc-win32. That should cover 99% of our users.