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
which brings up another question that i can't really decide from a distance... should this new system be based on CFFI/C2FFI? or should it use hand written grovel files?
it needs groveling for definitions that are implemented as C macros, and the C standard is very liberal about allowing random stuff to be a macro, without a corresponding dlsym... which suggest that a hand written grovel file is the way to go, but then c2ffi can emit stuff that doesn't require the groveller, and is also automated. plus i've been planning to extend it to also emit a grovel file to accommodate for stuff that need groveling (e.g. inline functions if nothing else).
oh well... any insights? which side of this fork will lead to less pain?