mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Russell King <rmk@arm.linux.org.uk>
To: Der Herr Hofrat <der.herr@hofr.at>
Cc: linux-kernel@vger.kernel.org
Subject: Re: sizeof problem in kernel modules
Date: Sat, 23 Jun 2001 16:30:26 +0100	[thread overview]
Message-ID: <20010623163026.A27303@flint.arm.linux.org.uk> (raw)
In-Reply-To: <200106231454.f5NEsKu14812@kanga.hofr.at>
In-Reply-To: <200106231454.f5NEsKu14812@kanga.hofr.at>; from der.herr@hofr.at on Sat, Jun 23, 2001 at 04:54:20PM +0200

On Sat, Jun 23, 2001 at 04:54:20PM +0200, Der Herr Hofrat wrote:
> struct { short x; long y; short z; }bad_struct;
> struct { long y; short x; short z; }good_struct;
> 
> I would expect both structs to be 8byte in size , or atleast the same size !
> but good_struct turns out to be 8bytes and bad_struct 12 .
> 
> what am I doing wrong here ?

You're expecting the compiler to lay them out without any spacing between
them.  There is no such requirement in C.

The compiler knows that its more efficient for long words to be accessed
on a long word boundary, so it wastes two bytes after each short in your
bad_struct case.  However, it won't waste them in this case, because there
isn't a long:

struct { short x; short y; short z; }

If you really really really want that layout, then use
__attribute__((packed)) (read the gcc info files to find out what this
does), but don't unless you absolutely must.

Here is another struct layout example:

struct foo {
	short x;
	char y;		/* implicit 1 byte padding after this element */
	short z;
};

Again, the 1 byte padding can be removed by use of the __attribute__
above.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


  parent reply	other threads:[~2001-06-23 15:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-23 14:54 Der Herr Hofrat
2001-06-23 15:18 ` Keith Owens
2001-06-23 15:30 ` Russell King [this message]
2001-06-24  1:56 ` Richard B. Johnson
2001-06-24  2:12   ` Keith Owens
2001-06-24  2:43     ` Richard B. Johnson
2001-06-24 16:07       ` Lieven Marchand
2001-06-24 16:11       ` frank
2001-06-25  0:26       ` Michael Meissner
2001-06-25 11:32         ` Richard B. Johnson
2001-06-25 13:38           ` Alan Shutko
2001-06-25 14:49             ` Richard B. Johnson
2001-06-25 19:19               ` Alan Shutko
2001-06-25 13:59           ` Alan Shutko
2001-06-25 15:07             ` Andreas Schwab
2001-06-25 21:25             ` Horst von Brand
2001-06-25 20:43           ` Michael Meissner
2001-06-25  4:33 ` Anil Kumar

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=20010623163026.A27303@flint.arm.linux.org.uk \
    --to=rmk@arm.linux.org.uk \
    --cc=der.herr@hofr.at \
    --cc=linux-kernel@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®