grovel-headers is deficient

[Douglas Katzman]

grovel-headers does not know that implementors of libc and /usr/include headers can add more fields to pad out a structure because it only prints into its output the sizes of the field names it expects.

https://git.musl-libc.org/cgit/musl/tree/include/alltypes.h.in
defines:

typedef long long time_t;
STRUCT timespec {
 time_t tv_sec;
 int :8*(sizeof(time_t)-sizeof(long))*(__BYTE_ORDER==4321);
 long tv_nsec;
 int :8*(sizeof(time_t)-sizeof(long))*(__BYTE_ORDER!=4321);
};

I've added newlines for readability but it's otherwise verbatim.

Lisp sees this definition in stuff-groveled-from-headers:
(define-alien-type nil
  (struct timespec
          (tv-sec (signed 64))
          (tv-nsec (signed 32))))

The library wants the structure to be the physical size of two occurrences of 'time_t' (8 byte each) but there is a trailing anonymous field (on little-endian; big-endian would have the anonymous field in the middle). More interestingly, the _implementation_ of the library writes to the anonymous field. Actually that may not be 100% correct; I think it's the kernel doing to store because gdb shows:
(gdb) backtrace
#0 0xb7f5b2b2 in __vdso_clock_gettime64 ()
#1 0xb7dc5000 in ?? ()
#2 0xb7fbe2cc in __clock_gettime (clk=6, ts=0xb7dc3ff4) at src/time/clock_gettime.c:67

And then the library has the data where expected.

So perhaps the scary-sounding email I send to sbcl-devel in response to the problem reported regarding Alpine linux is really only applicable to structure definitions that are opaque to grovel-headers and it's not more generally an ABI problem. The thing is, we don't know what structures have this problem.

Quite possibly this is also the cause of https://bugs.launchpad.net/sbcl/+bug/2063340