mailing list of musl libc
 help / color / mirror / code / Atom feed
* [musl] Confused length of `sigset_t`
@ 2022-06-27 15:49 张 译仁
  2022-06-27 16:18 ` Florian Weimer
  0 siblings, 1 reply; 3+ messages in thread
From: 张 译仁 @ 2022-06-27 15:49 UTC (permalink / raw)
  To: musl

[-- 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 --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [musl] Confused length of `sigset_t`
  2022-06-27 15:49 [musl] Confused length of `sigset_t` 张 译仁
@ 2022-06-27 16:18 ` Florian Weimer
  2022-06-27 20:27   ` Rich Felker
  0 siblings, 1 reply; 3+ messages in thread
From: Florian Weimer @ 2022-06-27 16:18 UTC (permalink / raw)
  To: 张 译仁; +Cc: musl

* 张 译仁:

> 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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [musl] Confused length of `sigset_t`
  2022-06-27 16:18 ` Florian Weimer
@ 2022-06-27 20:27   ` Rich Felker
  0 siblings, 0 replies; 3+ messages in thread
From: Rich Felker @ 2022-06-27 20:27 UTC (permalink / raw)
  To: Florian Weimer; +Cc: 张 译仁, musl

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-06-27 20:28 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-27 15:49 [musl] Confused length of `sigset_t` 张 译仁
2022-06-27 16:18 ` Florian Weimer
2022-06-27 20:27   ` Rich Felker

Code repositories for project(s) associated with this inbox:

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).