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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.