From: Jon Grimm <jgrimm2@us.ibm.com>
To: Bruce Allan <bwa@us.ibm.com>,
davem@redhat.com, lksctp-developers@lists.sourceforge.net,
linux-net@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: [Lksctp-developers] Re: [PATCH] subset of RFC2553
Date: Wed, 19 Feb 2003 18:23:06 -0600 [thread overview]
Message-ID: <3E541FEA.C34BEEB7@us.ibm.com> (raw)
In-Reply-To: 3E54128C.327D7759@us.ibm.com
Or if you don't care about the alignment of the __data field at all:
#define _SS_MAXSIZE 128
#if ULONG_MAX > 0xffffffff
#define _ALIGNSIZE ((sizeof(__u64)))
#else
#define _ALIGNSIZE ((sizeof(__u32)))
#endif
struct sockaddr_storage {
sa_family_t ss_family;
char __data[_SS_MAXSIZE-sizeof(sa_family_t)*2 + _ALIGNSIZE];
} __attribute ((aligned(_ALIGNSIZE)));
jon
Jon Grimm wrote:
>
> Bruce Allan wrote:
> >
> > How about this instead (a combination of your comment above and glibc's
> > definition of sockaddr_storage):
> > #define _SS_MAXSIZE 128
> > #define _ALIGNSIZE (sizeof(struct sockaddr *))
> > #if ULONG_MAX > 0xffffffff
> > #define __ss_aligntype __u64
> > #else
> > #define __ss_aligntype __u32
> > #endif
> > struct sockaddr_storage {
> > sa_family_t ss_family;
> > __ss_aligntype __data[(_SS_MAXSIZE/sizeof(__ss_aligntype))-1];
> > } __attribute__ ((aligned(_ALIGNSIZE)));
> >
>
> Hmmm... this seemed to generate a 124-byte struct instead of the stated
> intent of 128.
>
> Maybe instead:
>
> #define _SS_MAXSIZE 128
> #if ULONG_MAX > 0xffffffff
> #define __ss_aligntype __u64
> #else
> #define __ss_aligntype __u32
> #endif
> #define _ALIGNSIZE (sizeof(__ss_aligntype))
> struct sockaddr_storage {
> sa_family_t ss_family;
> __ss_aligntype __data[_SS_MAXSIZE/_ALIGNSIZE-1] __attribute__
> ((aligned(_ALIGNSIZE)));
> } __attribute ((aligned(_ALIGNSIZE)));
>
> Align the struct on _ALIGNSIZE; align _data on _ALIGNSIZE to to generate
> padding between ss_family and __data.
>
> Best Regards,
> jon
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Lksctp-developers mailing list
> Lksctp-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lksctp-developers
next prev parent reply other threads:[~2003-02-20 0:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-19 2:32 [PATCH] subset of RFC2553 Bruce Allan
2003-02-19 23:26 ` [Lksctp-developers] " Jon Grimm
2003-02-20 0:21 ` David S. Miller
2003-02-21 17:06 ` Bruce Allan
2003-02-22 7:23 ` David S. Miller
2003-02-22 7:26 ` David S. Miller
2003-02-24 17:54 ` Bruce Allan
2003-03-03 8:44 ` David S. Miller
2003-02-22 9:26 ` Pekka Savola
2003-02-20 0:23 ` Jon Grimm [this message]
2003-02-20 1:28 ` [Lksctp-developers] " Jon Grimm
2003-02-20 20:53 ` Bruce Allan
2003-02-20 21:24 ` Jon Grimm
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=3E541FEA.C34BEEB7@us.ibm.com \
--to=jgrimm2@us.ibm.com \
--cc=bwa@us.ibm.com \
--cc=davem@redhat.com \
--cc=linux-net@vger.kernel.org \
--cc=lksctp-developers@lists.sourceforge.net \
--cc=netdev@oss.sgi.com \
/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 NNTP newsgroup(s).