> A slightly more difficult situation is what to do with sigsets
> smaller than the kernel's, at least if we do manage to decouple
> libc from other libraries from the application. Consider the
> common idiom:
>
> struct sigaction new, old;
>
> new = ...
> sigaction(SIGFOO, &new, &old);
> ...
> sigaction(SIGFOO, &old, NULL);
>
> which assumes that things are restored intact. But if this bit were
> in a library and the application was using a larger sigset, then
> the top bits will be lost.
I don't think this is a problem. First we introduced a sigset_t which
is hopefully large enough for the next years in glibc (1024 signals).
Second, changing the size of the sigset_t etc is an incompatible
change which is not done without protection. In the above case the
`sigaction' function will be a wrapper around the sys_xsigaction
syscall which is in the libc. When some day the size of sigset_t is
changed and the implementation in the libc has to changed, we'll use
the symbol versioning of glibc-2.1 and above to hide this. Old
program will continue to work since the old definition of sigaction
will still be available for them.
-- Uli
---------------. drepper@cygnus.com ,-. Rubensstrasse 5
Ulrich Drepper \ ,-------------------' \ 76149 Karlsruhe/Germany
Cygnus Solutions `--' drepper@gnu.ai.mit.edu `------------------------