> > btw. would it be Ok on signal delivery, to just copy the actually used
> > portion of siginfo_t (i.e. what's currently ksiginfo_t) to the signal
> > handler's stack instead of all of the 128 "future expansion" bytes?
> 
> The kernel does this, yes? Then it should be fine to just zero the rest.

The point is that I don't want to copy the slack out at all. Currently,
only 32 bytes of the 128 byte siginfo_t structure are meaningful. I've got
other plans for my cpu cycles..

The same goes for ucontext_t, btw., which I've also cut short.


> > I can only see potential confusion if a program that's compiled using
> > a future version of siginfo.h is run on an older kernel, which would
> > be something that's inadvisable anyway.
> 
> If you zero the rest (set to known value :-) then programs should be ok. 
> Though in general we don't support running programs on kernels older than 
> the userland they were built for.

Duh.. a (future) program may not be able to tell the difference between
some value being zero (or whatever other known value) meaning "empty,
do not use!" and "here's some interesting attribute of object foo" that
happens to have the value 0.

The unionized nature of siginfo_t certainly doesn't help with that either.

If we really care about this, we should add a version number.

-pk