From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by sourceware.org (Postfix) with ESMTPS id 40BE6385842D for ; Fri, 20 Jan 2023 10:07:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 40BE6385842D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x52f.google.com with SMTP id v10so6106038edi.8 for ; Fri, 20 Jan 2023 02:07:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=sRo27/PYWmZ4FopKtG2CjACVTRyMIbWssLzOvhuBLKE=; b=DBWndoGrfdumvsAPs8YmivpDwhCjcxfkPwoy6MC+KW7eAH4V0hJS7ojGPArL2o4DNa 5ny7uizob7jgy40ewL3fHman9S8hw9C3aGz5vyfwNJNp+sPrbV0m8PO+YaG6N5GFZbx9 2iB+YM48rwCQWl5LyHgXJ0TL8mwXRBWS4Kjfxv3DH0/qrkRgGjKsaPcu/BPAr8tWYfP3 tLkt66hlUxh4xLJuv6Tra7JCiurtJOG7S0zovRLWlMtt79yZgX145wOaZQLXo+/Wb4GH bhIL54gtim+/XO0v6DpGFnnzDyVQvt4//mKfiWLZqJgjpUCxRAt0PA+J+AgeDzfpNCvA SCRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=sRo27/PYWmZ4FopKtG2CjACVTRyMIbWssLzOvhuBLKE=; b=u0tfh3oZGMyu/A0So7bZ5VsRX6HxeQAIL6dygp0F1hKrxYR8scey2/JsogRKNbzgKc aSJL4EqHz4QqgvydImfS2kcxbKk9F0KEqBMQsFN8ko4QC/u0HCjHWJvZ4+ApRn4nZuck iwyhltGghu/a7Ki9q11djsjWLjgX0t8JpXtZdDcx0QXCV125W402GCzIGRDTHor/KvK6 M9ltcLZqvs2tzjkMEQwVjMYC7VQb/DCC8tKAlqiMNReEVpeH03aB1kjyclphoZTuf8+M fWIEq37RWYNrQnzKgz+EwSKt00HsiCEhdYqgCfizHNtmg62k5EhuvCOabI0+vAkm61nu gzBA== X-Gm-Message-State: AFqh2kq6dBYwlBLtPmffw9MKrY89wQB85EFvIyhHzu8cXaIEMPO+6Pkw lQHLIZn+QIK5z04GePzm1tuBTaZR9F+7/MjYg2s= X-Google-Smtp-Source: AMrXdXuQ/0wr3nb6+MmHFjyyvyoFgO50VhXGdhv2Oc9PGiRZW6lrCTqvVsTV3dZE0wmIaImeIGyYK3Vgn1FZ/FD2hAc= X-Received: by 2002:a05:6402:707:b0:49e:1502:46d6 with SMTP id w7-20020a056402070700b0049e150246d6mr1664093edx.197.1674209221939; Fri, 20 Jan 2023 02:07:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Stefan Puiu Date: Fri, 20 Jan 2023 12:06:50 +0200 Message-ID: Subject: Re: struct sockaddr_storage To: Alejandro Colomar Cc: GNU C Library , linux-man , gcc@gcc.gnu.org, Igor Sysoev Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,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: Hi Alex, On Thu, Jan 19, 2023 at 4:14 PM Alejandro Colomar wrote: > > Hi! > > I just received a report about struct sockaddr_storage in the man pages. It > reminded me of some concern I've always had about it: it doesn't seem to be a > usable type. > > It has some alignment promises that make it "just work" most of the time, but > it's still a UB mine, according to ISO C. > > According to strict aliasing rules, if you declare a variable of type 'struct > sockaddr_storage', that's what you get, and trying to access it later as some > other sockaddr_8 is simply not legal. The compiler may assume those accesses > can't happen, and optimize as it pleases. Can you detail the "is not legal" part? How about the APIs like connect() etc that use pointers to struct sockaddr, where the underlying type is different, why would that be legal while using sockaddr_storage isn't? Will code break in practice? > > That means that one needs to declare a union with all possible sockaddr_* types > that are of interest, so that access as any of them is later allowed by the > compiler (of course, the user still needs to access the correct one, but that's > of course). > > In that union, one could add a member that is of type sockaddr_storage for > getting a more consistent structure size (for example, if some members are > conditional on preprocessor stuff), but I don't see much value in that. > Especially, given this comment that Igor Sysoev wrote in NGINX Unit's source code: > > * struct sockaddr_storage is: > * 128 bytes on Linux, FreeBSD, MacOSX, NetBSD; > * 256 bytes on Solaris, OpenBSD, and HP-UX; > * 1288 bytes on AIX. > * > * struct sockaddr_storage is too large on some platforms > * or less than real maximum struct sockaddr_un length. > > Which makes it even more useless as a type. I'm not sure using struct sockaddr_storage for storing sockaddr_un's (UNIX domain socket addresses, right?) is that common a usage. I've used it in the past to store either a sockaddr_in or a sockaddr_in6, and I think that would be a more common scenario. The comment above probably makes sense for nginx, but different projects have different needs. As for the size, I guess it might matter if you want to port your code to AIX, Solaris, OpenBSD etc. I don't think all software is meant to be portable, though (or portable to those platforms). Maybe a warning is in order that, for portable code, developers should check its size on the other platforms targeted. Just my 2 cents, as always, Stefan. > > > Should we warn about uses of this type? Should we recommend against using it in > the manual page, since there's no legitimate uses of it? > > Cheers, > > Alex > > -- >