All of lore.kernel.org
 help / color / mirror / Atom feed
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).

  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.