On Wed, Jan 19, 2000 at 02:04:08PM +0000, Alan Cox wrote:
> > BTW: When hacking on the patch, I found that on i386 glibc defines siginfo_t
> > to have a 32bit uid in the place of kernel's 16bit (but the kernel has
> > padding there), which leads me to the question: is it really necessary to
> > keep _kill._uid on intel with 16bit type and introduce _kill._uid32?
>
> You answered that question yourself. The other two bytes are undefined on
> older kernels
They are undefined, yet should be cleared by the kernel which the kernel
usually does not clear.
With 2.3.39 and prior kernels, all glibc programs using si_uid get broken
values (because glibc uses a 32bit type for si_uid and thus gets usually
upper 16 bits of id garbage - running my siginfotest.c on glibc gives me
bogus si_uid like -939655168) and as I have not seen anybody complaining
about this, it makes me think not too many programs are actually using it so
far, especially libc5.
So the question is whether to fix current glibc programs, make things less
complicated and break libc5 (well, breaking means worst that on a system with uids
above 65535 you get the value truncated with old libc5 program,
recompilation helps) or leave the ._uid32 stuff in and keep glibc programs
broken and have to teach new glibc/libc5 programs about larger uids which
are somewhere else in the structure.
Cheers,
Jakub
___________________________________________________________________
Jakub Jelinek | jakub@redhat.com | http://sunsite.mff.cuni.cz/~jj
Linux version 2.3.40 on a sparc64 machine (1343.49 BogoMips)
___________________________________________________________________
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:21 EST