On Wed, Jan 19, 2000 at 02:30:31PM +0000, Alan Cox wrote:
> > 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
>
> Ok this was the bit I was unware of. I assumed glibc did the right thing.
> Also on different endian processors you will get differently inconvenient
> results, which side does the compiler pad ?
All but arm, i386 and m68k used 32bit type there already.
The only broken big endian is m68k, but there I think we should switch
to 32bit type as well, because all glibc programs would have to do
((unsigned int)si_uid)>>16 to get right pid if they wanted to work
previously (m68k uses int as __uid_t which is used in glibc siginfo_t).
>
> > 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
>
> Andreas said that libc5 doesnt use siginfo stuff anyway ?
Well, I think it does not provide you the rt signal syscalls, but you can
still call sigaction with SA_SIGINFO and look from the signal handler at
its arguments. But I think people rarely do it in libc5.
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:20 EST