From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id C833523514 for ; Wed, 24 Apr 2024 02:45:47 +0200 (CEST) Received: (qmail 5184 invoked by uid 550); 24 Apr 2024 00:45: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 5145 invoked from network); 24 Apr 2024 00:45:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mforney.org; s=google; t=1713919533; x=1714524333; darn=lists.openwall.com; h=user-agent:message-id:in-reply-to:references:from:subject:cc:to :date:from:to:cc:subject:date:message-id:reply-to; bh=qsRKpoGqJ/h/O1LnJfNubSXsc/cX1CGggzDmV9+sBIY=; b=KVFYoie0M5mbIXax/r4Jy38CzYJfyvKs73kwr/u85ZENGr2PtBmzmpg+4oFiEyIdKv WYN9ClnmFMeSc8TfC5nQRm+e4xTc9TACX+4+Nk9RHawDsAPFJeOTxsdM7eF9IpbtTnKv apvAgGxjcn0dl0SXxhunSuCp4OxwLkEnJDdvssJVv7kOvhxBtHAMygIp30//yJ67f8eP FvVY0rQMdh70gb/Irk28+G1wL488D7muUlefSJrMtzZoLNP7d2btEZOWDwjX8jO1/pgi Ujk2OnRb6TMxxssJW7q3z3yvWQYeJEd63iFZYArLxs/i68Z8ZWNyYxOV9yx6IRJPKVKR 9J5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713919533; x=1714524333; h=user-agent:message-id:in-reply-to:references:from:subject:cc:to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=qsRKpoGqJ/h/O1LnJfNubSXsc/cX1CGggzDmV9+sBIY=; b=iFjHYrY+xC5pwwX0633TQkk6gcAKIvN8k6wMSGQjNIKhedTWeqflnwD92dfldghWjI lDZQ+heeiKwW9liuZ5ifFKZIBfziV3FP/eSI8vj2aitrACIT7yS/t/i6ylOQfR11kvbU tbcgqePtUWqI8iIRKkpmSKeHieI4Dhp1B6YP2S25vDBcBO7IhCpfP6EnkEC/HyDjGXf7 bu2YEXjlduzB+7x3f2gAHPDJ7H8WiaZxAIDb1xa4D00FX1Hz8D53M5og9X5OQ6FURwbI Zg1TQAR5go/qC4mbW8IXHSZ+ii/PPLH2oWt4pgOhGaKSqZ/7DK7LyjLzHTUDUgabm0kv p8BA== X-Gm-Message-State: AOJu0YzL79s9D/PE5QA1w3VjBDU949NqaQ5n9Kk3yBIqhcvEUJ/LdJUy vD2318DZOsok43GPtU3SnXFFiDTG30XTkFAhK2SZR1muuEqzEqBrcBt9juGKjH8= X-Google-Smtp-Source: AGHT+IHMuPrUYDqQ+jOHx4QBhfAyTO43st0VHIJbB+iKwOvG9HQuc0IOrvYym3HJ8bfLlCPdJXmn7g== X-Received: by 2002:a17:90a:f00f:b0:2aa:d88d:d706 with SMTP id bt15-20020a17090af00f00b002aad88dd706mr5551437pjb.4.1713919533310; Tue, 23 Apr 2024 17:45:33 -0700 (PDT) Date: Tue, 23 Apr 2024 17:45:31 -0700 To: Rich Felker Cc: musl@lists.openwall.com From: Michael Forney References: <3KDMGHI91MHTL.24XCHF6E4X1XG@mforney.org> <20240421234809.GK4163@brightrain.aerifal.cx> In-Reply-To: <20240421234809.GK4163@brightrain.aerifal.cx> Message-Id: <1Z2XU7Z5OB2AV.26EJYFLGNXL0W@mforney.org> User-Agent: mblaze/1.2 Subject: Re: [musl] Alignment attribute in headers Rich Felker wrote: > Most of these I didn't remember, and were likely added begrudgingly. > There's really no point in having alignment specifiers on the > sigcontext/mcontext stuff, as it's kernel-allocated. If there are > places where explicit padding to match the layout is missing, these > are bugs and should be corrected. I tried to get explicit padding put > everywhere, asking folks doing new ports to add it (or refrain from > deleting it), but it's possible some places were missed. Let's fix > them. I checked the other instances, and I think the ones that Markus identified (riscv32/riscv64 bits/signal.h) are the only ones that are missing padding. I can prepare a patch if Markus doesn't plan to. > For all of this, I think it's perfectly acceptable to just use the GNU > C attribute and condition it on __GNUC__. Once any missing padding is > fixed, the alignment attribute doesn't really matter. If there's really no point to the alignment specifiers for mcontext sub-structures, should they just be removed completely? If there is a point to the alignment specifiers, I think the structs should be defined in such a way that their alignment doesn't depend on the compiler you used. My worry is that some application might use these structs as fields inside their own structs, and save data from a signal handler in them. Without the alignment specifier, they could potentially have incorrect offsets, breaking ABI compatibility between GNU C and non-GNU C compilers. For x32 struct shm_info, the structure is allocated by the application. Even if the kernel doesn't care when populating it, it seems plausible to me that it might be part of a larger struct. > > Something like > > > > #if __STDC_VERSION__ >= 201112L > > /* use _Alignas */ > > #elif defined(__cplusplus) && !defined(__GNUC__) > > /* use alignas */ > > #else > > /* use __attribute__((__aligned__(N))) */ > > #end > > For arch-specific bits where the GNUC attribute can be considered part > of the psABI requirements, while I don't like this, my leaning is that > it's fine to use it directly and ignore the C11 and C++11 versions. > > I think public interfaces that are not arch-specific should avoid > depending on it, but the only one of these is sys/fanotify.h, which is > very much a Linuxism feature and it doesn't seem that bad for it to > fail on weird compilers. Why ignore the C11/C++11 versions? I know it's somewhat annoying to handle the different cases, but that seems better to me than to sacrifice correctness on compilers that don't support the attribute.