From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by sourceware.org (Postfix) with ESMTPS id D80A53858430 for ; Fri, 20 Jan 2023 18:04:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D80A53858430 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=owlfolio.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=owlfolio.org Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id AFEEB5C0058; Fri, 20 Jan 2023 13:04:49 -0500 (EST) Received: from imap45 ([10.202.2.95]) by compute1.internal (MEProxy); Fri, 20 Jan 2023 13:04:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1674237889; x=1674324289; bh=Jgm6+mnRai 49Ie+6zLqoN91E8e+nrZZO2RfDdiqlPoQ=; b=JyZEa1L5gwbS3A7U7lYD5U3757 ZKqTPIMUZ4wU5r16YOMie0C/U+pVAg4LqD3GCV4ozvjjPDU95yTsWF7cFu/+chr3 fH1gg1wKbf//NCI8OMwJhKR+9xOdddp99aMzlo1u5faur66xikblimBisRh4M4O6 8QIqlNIZBoBY9R1uFFHRix1J7cBRpPeXnUBapzpN0pAJsyQ+18P32XZoGr+pwcV+ Do0QyeDGhb2Mu4Et3Y2TOnvXUK9sbh4OaX/QVsVUJ6YVVWs//qRsXZMp/26e4Tka Wni4uXwohaIvmYSyhvVNzDHlTeas+LfYBg9OkPH8qOE/zFgi0dnnLASHrHnQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1674237889; x=1674324289; bh=Jgm6+mnRai49Ie+6zLqoN91E8e+n rZZO2RfDdiqlPoQ=; b=JfCtFDfXoAwEfKlSMbDG5LyK9Enz70etF+1W8dwAXOE7 TyIxtWC3AlbxSPa5DhFBaskGX0MSo/jtJhPZ5TCKeDW2b/b/zbKJ8NS2knOflJKn AIiZC6hFNg6sUpDwm4tt42FjUSPvTe/Ielx3/xm0ElLE3282iX3ViklcBzWdmLA2 0mvLAIspR23pMVfCLMowhMpByn2HyJn4C+1QIOe7cBl1rb994NaZEpX0iKd/1coF aOgpXinvZFxPanLvmJrx+YYqaFJ3wG0CjeKmRZ4qOCqxMWsFp8nynjf+7vSENmRz wN8WUUhx5YboI3uqj1xebEALQIJDIfam9sFLkNSs6g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudduvddguddutdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdgk rggtkhcuhggvihhnsggvrhhgfdcuoeiirggtkhesohiflhhfohhlihhordhorhhgqeenuc ggtffrrghtthgvrhhnpefgleehveejhefgffetgffhveefvdekgeehtdffleeihfevgeei ffduveffgeeiudenucffohhmrghinhepghhouggsohhlthdrohhrghdpshhtrggtkhhovh gvrhhflhhofidrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpeiirggtkhesohiflhhfohhlihhordhorhhg X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2013C272007B; Fri, 20 Jan 2023 13:04:49 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-85-gd6d859e0cf-fm-20230116.001-gd6d859e0 Mime-Version: 1.0 Message-Id: In-Reply-To: <20230120134043.10247-1-alx@kernel.org> References: <20230120134043.10247-1-alx@kernel.org> Date: Fri, 20 Jan 2023 13:04:26 -0500 From: "Zack Weinberg" To: "'Alejandro Colomar (man-pages)'" , "GNU libc development" Cc: "Alejandro Colomar" , 'linux-man' , =?UTF-8?Q?Bastien_Roucari=C3=A8s?= , "Eric Blake" , "Stefan Puiu" , "Igor Sysoev" Subject: Re: [PATCH v2] socket: Implement sockaddr_storage with an anonymous union Content-Type: text/plain X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Jan 20, 2023, at 8:40 AM, Alejandro Colomar wrote: > The historical design of `sockaddr_storage` makes it impossible to use > without breaking strict aliasing rules. Not only this type is unusable, > but even the use of other `sockaddr_*` structures directly (when the > programmer only cares about a single address family) is also incorrect, > since at some point the structure will be accessed as a `sockaddr`, and > that breaks strict aliasing rules too. > > So, the only way for a programmer to not invoke Undefined Behavior is to > declare a union that includes `sockaddr` and any `sockaddr_*` structures > that are of interest, which allows later accessing as either the correct > structure or plain `sockaddr` for the sa_family. ... > struct new_sockaddr_storage nss; > > // ... (initialize oss and nss) > > inet_sockaddr2str(&nss.sa); // correct (and has no casts) I think we need to move slowly here and be _sure_ that any proposed change does in fact reduce the amount of UB. This construct, in particular, might not actually be correct in practice: see https://godbolt.org/z/rn51cracn for a case where, if I'm reading it right, the compiler assumes that a write through a `struct fancy *` cannot alter the values accessible through a `struct simple *` even though both pointers point into the same union. (Test case provided by ; I don't know any other identifier for them.) zw