siginfo_t si_band type mismatch between kernel & glibc

siginfo_t si_band type mismatch between kernel & glibc

[Lars Marowsky-Bree]

Morning,

it turns out that on some archs, si_band is defined as long in the glibc
headers and as int in the kernel, leading to a 'nice' struct mismatch
and quite interesting behaviour - ie, breaking SIGPOLL & SIGIO on most
64bit archs.

In 2.6, we find:

#ifndef __ARCH_SI_BAND_T
#define __ARCH_SI_BAND_T int
#endif
...
                /* SIGPOLL */
                struct {
                        __ARCH_SI_BAND_T _band; /* POLL_IN, POLL_OUT, POLL_MSG */
                        int _fd;
                } _sigpoll;


Alas, for all archs but x86_64, __ARCH_SI_BAND_T is not defined, thus
defaulting to int, which is still not matching the user space expectations.

http://linux.bkbits.net:8080/linux-2.5/diffs/include/asm-generic/siginfo.h@1.10?nav=index.html|src/|src/include|src/include/asm-generic|hist/include/asm-generic/siginfo.h
suggests that Linus believes _band should be int on all archs but x86_64.

However, the glibc has had it as 'long' on mips, ia64 and x86_64 in the
kernel-headers; the glibc/sysdeps differs from this further, as it is
long only on linux(generic), ia64, s390. And the manpage says it to be
int, fwiw.

So is this a kernel bug or a glibc one? ;-)

Most user-land seems to expect it to be long, and right now (in 2.4 +
2.6), it seems SIGIO is definetely broken on ppc64 / s390x.


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering	      \ ever tried. ever failed. no matter.
SUSE Labs			      | try again. fail again. fail better.
Research & Development, SUSE LINUX AG \ 	-- Samuel Beckett