public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: Stefano Brivio <sbrivio@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: passt-dev@passt.top
Subject: Re: [PATCH 5/8] util: Improve sockaddr initialisation in sock_l4()
Date: Wed, 27 Dec 2023 21:25:15 +0100	[thread overview]
Message-ID: <20231227212515.04a42717@elisabeth> (raw)
In-Reply-To: <20231207143140.1851378-6-david@gibson.dropbear.id.au>

On Fri,  8 Dec 2023 01:31:37 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> Currently we initialise the address field of the sockaddrs we construct
> to the any/unspecified address, but not in a very clear way: we use
> explicit 0 values, which is only interpretable if you know the order of
> fields in the sockaddr structures.  Use explicit field names, and explicit
> initialiser macros for the address.
> 
> Because we initialise to this default value, we don't need to explicitly
> set the any/unspecified address later on if the caller didn't pass an
> overriding bind address.
> 
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
>  util.c | 8 ++------
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/util.c b/util.c
> index d465e48..0152ae6 100644
> --- a/util.c
> +++ b/util.c
> @@ -105,12 +105,12 @@ int sock_l4(const struct ctx *c, int af, uint8_t proto,
>  	struct sockaddr_in addr4 = {
>  		.sin_family = AF_INET,
>  		.sin_port = htons(port),
> -		{ 0 }, { 0 },
> +		.sin_addr = IN4ADDR_ANY_INIT,

The second { 0 } was meant to initialise .sin_zero, and:

>  	};
>  	struct sockaddr_in6 addr6 = {
>  		.sin6_family = AF_INET6,
>  		.sin6_port = htons(port),
> -		0, IN6ADDR_ANY_INIT, 0,
> +		.sin6_addr = IN6ADDR_ANY_INIT,

these zeroes were for sin6_flowinfo and sin6_scope_id.

Not needed because we want zeroes anyway (or the "same as objects that
have static storage duration"), but see commit eed6933e6c29 ("udp:
Explicitly initialise sin6_scope_id and sin_zero in sockaddr_in{,6}"):
gcc versions 7 to 9 used to complain. And gcc 9 isn't *that* old.

But then, you might ask, why didn't I just use names for all the
initialisers? Well, there was some issue with sockaddr_in6 or
sockaddr_in not having a field defined in some header (kernel or a C
library). I have a vague memory it was about sin6_scope_id, but I can't
find any note in the git history or anywhere else. :(

Now, the latest addition to sockaddr_in6 was sin6_scope_id (kernel:
2006, glibc: 2000), so that's fine. Also sockaddr_in looks okay,
including sin_zero, with "#define sin_zero __pad" in the kernel version.

So... my preferred option would be to leave this untouched: the
initialisers you replaced are anyway all zeroes. And, after RFC 2553
(24 years ago), the order of those fields never changed.

If it really bothers you, let's at least initialise everything
explicitly by name, because we know that gcc 9 complains, and if we hit
another version of sockaddr_in6 without a named sin6_scope_id, we'll
find out, eventually.

The rest of the series looks good to me and I just applied it (minus
_this part_ of this patch).

-- 
Stefano


  reply	other threads:[~2023-12-27 20:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-07 14:31 [PATCH 0/8] Small cleanups related to addresses and binding David Gibson
2023-12-07 14:31 ` [PATCH 1/8] tcp: Fix address type for tcp_sock_init_af() David Gibson
2023-12-27 20:25   ` Stefano Brivio
2023-12-28  2:42     ` David Gibson
2023-12-28 10:11       ` Stefano Brivio
2024-01-07  5:35         ` David Gibson
2024-01-13 22:50           ` Stefano Brivio
2023-12-07 14:31 ` [PATCH 2/8] treewide: Use IN4ADDR_LOOPBACK_INIT more widely David Gibson
2023-12-07 14:31 ` [PATCH 3/8] treewide: Add IN4ADDR_ANY_INIT macro David Gibson
2023-12-07 14:31 ` [PATCH 4/8] util: Use htonl_constant() in more places David Gibson
2023-12-07 14:31 ` [PATCH 5/8] util: Improve sockaddr initialisation in sock_l4() David Gibson
2023-12-27 20:25   ` Stefano Brivio [this message]
2024-01-07  5:34     ` David Gibson
2023-12-07 14:31 ` [PATCH 6/8] icmp: Avoid unnecessary handling of unspecified bind address David Gibson
2023-12-07 14:31 ` [PATCH 7/8] treewide: Avoid in_addr_t David Gibson
2023-12-07 14:31 ` [PATCH 8/8] util: Make sock_l4() treat empty string ifname like NULL David Gibson
2023-12-27 20:25 ` [PATCH 0/8] Small cleanups related to addresses and binding Stefano Brivio

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231227212515.04a42717@elisabeth \
    --to=sbrivio@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=passt-dev@passt.top \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://passt.top/passt

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 IMAP folder(s).