This is the mail archive of the
libc-alpha@sourceware.cygnus.com
mailing list for the glibc project.
Re: Fix struct siginfo
- To: Alan Cox <alan at lxorguk dot ukuu dot org dot uk>
- Subject: Re: Fix struct siginfo
- From: Andreas Jaeger <aj at suse dot de>
- Date: 19 Jan 2000 15:21:53 +0100
- Cc: torvalds at transmeta dot com, wingc at engin dot umich dot edu (Chris Wing),libc-alpha at sourceware dot cygnus dot com, linux-kernel at vger dot rutgers dot edu
- References: <E12Avfu-0007ZL-00@the-village.bc.nu>
>>>>> Alan Cox writes:
>> The fix for struct siginfo in 2.3.39 was not necessary since uid_t was
>> already aligned on a 32bit boundary for ix86 and arm. This patch
Alan> The other two bytes don't contain defined values for all 2.2.x/2.3.x kernels.
Alan> The memset to clear the other bits went in during 2.2.x so it isnt
Alan> safe to trust that an old kernel returns 0 for the padding. Earlier 2.2.x
Alan> hands back [Random.W}[uid.w]
And glibc relied on thisall the time, have a look at
<bits/siginfo.h>:
...
/* kill(). */
struct
{
__pid_t si_pid; /* Sending process ID. */
__uid_t si_uid; /* Real user ID of sending process. */
} _kill;
With those older kernel we loose already with glibc :-(.
Alan> Also the 16bit squashed uid format is important for the old binaries to get
Alan> correct data. You dont want uid 65536 being misinterpreted as uid 0 by
Alan> an old binary. The existing code hands back a plausible token, your change
Alan> appears not to do so.
What kind of old binaries? glibc 2.1 has externally 32bit uids - and
realtime signals (which use siginfo) are not supported by libc5 AFAIK.
Alan> You are right that the field is big enough on most architectures (not m68k
Alan> I think as that pads to word alignment - a quirk I had much fun with when
Alan> doing mac68k sysv fs support).
m68k pads to 16bit.
Alan> You are wrong that it is safe to use the other bytes.
I'm not convinced. Could you please check this again? I don't see
another way to handle it portably.
With my patch programs using struct siginfo continue to work correctly
- and no recompilation is necessary.
Andreas
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.rhein-neckar.de