public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx.manpages@gmail.com>
To: GNU C Library <libc-alpha@sourceware.org>
Cc: linux-man <linux-man@vger.kernel.org>,
	gcc@gcc.gnu.org, Igor Sysoev <igor@sysoev.ru>
Subject: struct sockaddr_storage
Date: Thu, 19 Jan 2023 15:11:26 +0100	[thread overview]
Message-ID: <ab492040-2058-bcbe-c920-a9088a20f071@gmail.com> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 1702 bytes --]

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.

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.


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

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

             reply	other threads:[~2023-01-19 14:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-19 14:11 Alejandro Colomar [this message]
2023-01-20 10:06 ` Stefan Puiu
2023-01-20 12:39   ` Alejandro Colomar
2023-01-23  7:40     ` Stefan Puiu
2023-01-23 16:03       ` Alejandro Colomar
2023-01-23 16:28         ` Richard Biener
2023-01-24 16:38           ` Alex Colomar
2023-01-23 16:37         ` Jakub Jelinek
2023-01-24 16:40           ` Alex Colomar
2023-01-24 18:00           ` Alex Colomar
2023-01-24 11:16   ` Rich Felker
2023-01-24 16:53     ` Alex Colomar

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=ab492040-2058-bcbe-c920-a9088a20f071@gmail.com \
    --to=alx.manpages@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=igor@sysoev.ru \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-man@vger.kernel.org \
    /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.
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 read-only IMAP folder(s) and NNTP newsgroup(s).