From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RDNS_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 17537 invoked from network); 27 Jun 2022 16:18:45 -0000 Received: from unknown (HELO mother.openwall.net) (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 27 Jun 2022 16:18:45 -0000 Received: (qmail 26113 invoked by uid 550); 27 Jun 2022 16:18:42 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 26087 invoked from network); 27 Jun 2022 16:18:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1656346710; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9dOO51J7AboFJTRqy/0ExQ27Ae/KOjuu7Rki97L/RdY=; b=SfFI8BAcl0vLPO5awLjaWPhh66wcrihe/G5ihbUIzxfv3P+O9+NVh6yy6XDovMtwRvYm4d rzbpmgWeeb2k767K9N0lHjLo7J9boBq0fXEwefZzjQ3quKA57dedthTIE2Wemp/JTQvRDJ 2VuEZFbxcG1B9+PKzjOLH6W9a0MzxCs= X-MC-Unique: z_8A6d-fMS-CzZgQT2TAxQ-1 From: Florian Weimer To: =?utf-8?B?5bygIOivkeS7gQ==?= Cc: "musl@lists.openwall.com" References: Date: Mon, 27 Jun 2022 18:18:26 +0200 In-Reply-To: (=?utf-8?B?IuW8oCDor5Hku4EiJ3M=?= message of "Mon, 27 Jun 2022 15:49:04 +0000") Message-ID: <87h7469j1p.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=fweimer@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Confused length of `sigset_t` * =E5=BC=A0 =E8=AF=91=E4=BB=81: > When supporting signal handling for my tiny OS, I notice that the definat= ion 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)]; } sig= set_t; > ``` > > 128 bytes (16 * long) are used for sigmask=E2=80=8B when 128 bits (2 * lo= ng) 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