git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] daemon.c: avoid accessing ss_family member of struct sockaddr_storage

From
Martin Storsjö <martin@martin.st>
Date
Mar 15, 2010, 21:41 UTC
Message-ID
<alpine.DEB.2.00.1003152338120.29993@cone.home.martin.st>
In-Reply-To
<20100315212915.GB25342@coredump.intra.peff.net>
On Mon, 15 Mar 2010, Jeff King wrote:
Show 13 quoted lines
> On Mon, Mar 15, 2010 at 04:03:00PM -0500, Brandon Casey wrote:
> 
> > When NO_SOCKADDR_STORAGE is set for a platform, either sockaddr_in or
> > sockaddr_in6 is used intead.  Neither of which has an ss_family member.
> > They have an sin_family and sin6_family member respectively.  Since the
> > addrcmp() function accesses the ss_family member of a sockaddr_storage
> > struct, compilation fails on platforms which define NO_SOCKADDR_STORGAGE.
> > 
> > Since any sockaddr_* structure can be cast to a struct sockaddr and
> > have its sa_family member read, do so here to workaround this issue.
> 
> Didn't Gary say that AIX 5.2 sticks sa_len at the front of their
> sockaddr?

Yes, but if they have it in sockaddr, they have it in sockaddr_in (and should have it in sockaddr_storage, if it defines such fields at all). Those structs should always be defined so that their sa_family/ss_family/sin_family/sin6_family fields match.

Show 8 quoted lines
> We know that whatever we actually have (an actual sockaddr_storage, or a
> sockaddr_in, or a sockaddr_in6) will have the family at the front, so
> can you just cast it to sa_family_t?
> 
> Or am I wrong in assuming that, and on AIX sockaddr_in actually has
> sa_len at the front, so casting to sockaddr does the right thing (and my
> recommendation above would actually be broken)? The AIX boxen I have
> access to are all down at the moment.

Generally, I don't think one can assume much about the layout of these structs, there may be this sa_len field on some implementations.

But you should always be able to cast a sockaddr_in or sockaddr_in6 or sockaddr_storage to a sockaddr, to examine its sa_family field, in order to know what to cast it to.

// Martin
Previous: Jeff KingNext: Brandon Casey
Message 7 of 17 in “struct sockaddr_storage->ss_family is not portable”
  1. 5/5 struct sockaddr_storage->ss_family is not portableGary V. Vaughan, Mar 11, 2010
  2. Martin StorsjöMar 11, 2010
  3. Gary V. VaughanMar 12, 2010
  4. Martin StorsjöMar 12, 2010
  5. daemon.c: avoid accessing ss_family member of struct sockaddr_storageBrandon Casey, Mar 15, 2010
  6. Jeff KingMar 15, 2010
  7. Martin StorsjöMar 15, 2010
  8. Brandon CaseyMar 15, 2010
  9. Gary V. VaughanApr 25, 2010
  10. Martin StorsjöMar 15, 2010
  11. daemon.c: avoid accessing ss_family member of struct sockaddr_storageBrandon Casey, Mar 15, 2010
  12. Martin StorsjöMar 16, 2010
  13. Gary V. VaughanApr 25, 2010
  14. Martin StorsjöApr 25, 2010
  15. Gary V. VaughanApr 26, 2010
  16. Jeff KingMar 11, 2010
  17. Brandon CaseyMar 11, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.