From: Thomas Heinz <creatix@hipac.org>
To: Laszlo Valko <valko@linux.karinthy.hu>
Cc: Anders Fugmann <afu@fugmann.dhs.org>,
netfilter-devel@lists.netfilter.org
Subject: Re: Comments about IPT_ALIGN
Date: Sun, 26 Jan 2003 20:48:53 +0100 [thread overview]
Message-ID: <3E343BA5.5030006@hipac.org> (raw)
In-Reply-To: 3E342355.1030707@hipac.org
I wrote:
> - the end of the struct must be marked by:
> struct ipt_entry next[0];
> or
> long next[0]; // I'm not sure about this!
Well, this is plain nonsense (I don't know why I wrote that).
But here is another idea that does not need #ifdefs:
struct info
{
[...]
} __attribute__((aligned(__alignof__(u_int64_t))));
This hopefully does the trick.
> - pointers or arrays of pointers should be avoided but if they're
> really needed (as in limit) a special pointer type should be
> used: 32 bit arch: union nf_ptr_t {void *p;
> u_int32_t padd;};
> 64 bit arch: union nf_ptr_t {void *p;
> u_int64_t padd;};
> Maybe there are better ways to achieve the same
> (__attribute__ ((aligned (__alignof__(long)))) might work).
^^^^^^^^^^
Of course it does _not_ :-)
I don't think there is a way to avoid the union which
leads to an #ifdef if we don't restrict ourselves to at most
one pointer at the end.
The reason for that is that it does not suffice to require
a certain alignment for void * but it also must have the
expected size. Otherwise members that come after pointer
members might have a different offset (just the same
argument as for long).
next prev parent reply other threads:[~2003-01-26 19:48 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-26 3:57 Comments about IPT_ALIGN Thomas Heinz
2003-01-26 11:01 ` Laszlo Valko
2003-01-26 11:28 ` Anders Fugmann
2003-01-26 13:58 ` Thomas Heinz
2003-01-26 14:26 ` Laszlo Valko
2003-01-26 16:50 ` Thomas Heinz
2003-01-26 19:31 ` Laszlo Valko
2003-01-31 11:51 ` Harald Welte
2003-01-26 14:22 ` Laszlo Valko
2003-01-26 18:05 ` Thomas Heinz
2003-01-26 19:43 ` Laszlo Valko
2003-01-26 23:09 ` Thomas Heinz
2003-01-27 0:43 ` Laszlo Valko
2003-01-27 10:33 ` Thomas Heinz
2003-01-31 11:57 ` Harald Welte
2003-01-26 19:48 ` Thomas Heinz [this message]
2003-01-31 11:55 ` Harald Welte
2003-01-31 23:37 ` Laszlo Valko
2003-01-26 17:06 ` Thomas Heinz
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=3E343BA5.5030006@hipac.org \
--to=creatix@hipac.org \
--cc=afu@fugmann.dhs.org \
--cc=netfilter-devel@lists.netfilter.org \
--cc=valko@linux.karinthy.hu \
/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.