[musl] Confused length of `sigset_t`

[musl] Confused length of `sigset_t`

[张 译仁]

[-- Attachment #1: Type: text/plain, Size: 452 bytes --]

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? In my opinion, `unsigned long __bits[128/sizeof(long)/8]` is more reasonable.

[-- Attachment #2: Type: text/html, Size: 2074 bytes --]

Re: [musl] Confused length of `sigset_t`

[Florian Weimer]

* 张 译仁:

> 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

Re: [musl] Confused length of `sigset_t`

[Rich Felker]

On Mon, Jun 27, 2022 at 06:18:26PM +0200, Florian Weimer wrote:
> * 张 译仁:
> 
> > 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.

Yes, that was the reason. However in musl it's also used in the
jmp_buf for a few extra words of storage to implement sigsetjmp.

Rich