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
Brandon Casey <casey@nrlssc.navy.mil>
Date
Mar 15, 2010, 21:42 UTC
Message-ID
<s0MQZSOEsdBJUhITxC3jwfFJk5PnIEo0WR5z_GEnSOw@cipher.nrlssc.navy.mil>
In-Reply-To
<20100315212915.GB25342@coredump.intra.peff.net>
On 03/15/2010 04:29 PM, Jeff King wrote:
Show 17 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?
> 
> 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?

I expect that the layout of the sockaddr_* family of structures will follow the layout of struct sockaddr, otherwise they wouldn't be compatible.

In other words, I think that if struct sockaddr looks like this:
  struct sockaddr {
        uchar_t         sa_len;         /* total length */
        sa_family_t     sa_family;      /* address family */
        char            sa_data[14];    /* actually longer; address value */
  };
then somewhere else, struct sockaddr_in looks like this:
  struct sockaddr_in {
        uchar_t         sin_len;
        sin_family_t    sin_family;
        sin_port;
        sin_addr;
        ...
  };
> 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.

Maybe Gary can check for us... Gary, what does the declaration for struct sockaddr_in look like in your AIX header file?

-brandon
Previous: Martin StorsjöNext: Gary V. Vaughan
Message 8 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.