[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87h7469j1p.fsf@oldenburg.str.redhat.com>
Date: Mon, 27 Jun 2022 18:18:26 +0200
From: Florian Weimer <fweimer@...hat.com>
To: 张 译仁 <zyr_ms@...look.com>
Cc: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Re: Confused length of `sigset_t`
* 张 译仁:
> When supporting signal handling for my tiny OS, I notice that the defination of `sigset_t`
> which is used in signal handling is weird.
>
> ```
> // include/alltypes.h.in
> TYPEDEF struct __sigset_t { unsigned long __bits[128/sizeof(long)]; } sigset_t;
> ```
>
> 128 bytes (16 * long) are used for sigmask when 128 bits (2 * long) is enough.
>
> Why? For strange compatibility?
I suspect it's for glibc compatibility. glibc did that in case the
kernel ever added support for more signals. The rt_sigprocmask system
call has a size argument, so it could potentially be extended beyond the
currently supported 64 or 128 bits (most architectures only support 64).
But later system calls that deal with signal sets do not take a size
argument, I think, so the extensibility just isn't there in practice,
and the glibc-reserved space is wasted.
Thanks,
Florian
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
