sizeof shows different size for a structure

[Anand Buddhdev]

Hi everyone,

I'm a C newbie, so please be gentle. I have a program that defines the
following things:

typedef union
{
unsigned int I;
unsigned char b[4];
} dword;

/* Structure for record 0 of the DAWG. */
typedef struct
{
unsigned char magic[5];
unsigned char name[11];
unsigned char title[41];
unsigned char desc[41];
unsigned char author[41];
unsigned char extra[41];
unsigned char ch[64];
unsigned char numchars;
unsigned char catsym[8];
unsigned char catname[8][11];
unsigned char catinclude[8][8];
unsigned char numcategories;
dword numnodes;
} dawghdr;

I expect the size of the dawghdr structure to be 410 bytes. However,
on compiling this program with gcc 3.3.2 on linux, dawghdr uses 412
bytes. I've examined the memory space of this structure, and it seems
to me that 2 extra bytes appear between the numcategories and numnodes
members. Could anyone be kind enough to explain why this might be
happening?

The program writes this structure to a disk file as a record, and I
later read this output file with a python script, but the script falls
over, as it fails to read the correct value of numnodes, since it has
no way of knowing about the 2 extra bytes.

[Christian Haselbach]

Anand Buddhdev <ar*@anand.or g> wrote:

I expect the size of the dawghdr structure to be 410 bytes. However,
on compiling this program with gcc 3.3.2 on linux, dawghdr uses 412
bytes. I've examined the memory space of this structure, and it seems
to me that 2 extra bytes appear between the numcategories and numnodes
members. Could anyone be kind enough to explain why this might be
happening?
The compiler is allowed to put padding between the elements.
This question is coverd in the faq:
http://www.eskimo.com/~scs/C-faq/q2.13.html
The program writes this structure to a disk file as a record, and I
later read this output file with a python script, but the script falls
over, as it fails to read the correct value of numnodes, since it has
no way of knowing about the 2 extra bytes.

This "solution" is highly compiler dependent. You should write an own
method. And don't forget to take care of endianess.

Ciao Chriss

[Darksun4]

"Anand Buddhdev" <ar*@anand.or g> wrote in message
news:7b******** *************** ***@posting.goo gle.com...

Hi everyone,

I'm a C newbie, so please be gentle. I have a program that defines the
following things:

typedef union
{
unsigned int I;
unsigned char b[4];
} dword;

/* Structure for record 0 of the DAWG. */
typedef struct
{
unsigned char magic[5];
unsigned char name[11];
unsigned char title[41];
unsigned char desc[41];
unsigned char author[41];
unsigned char extra[41];
unsigned char ch[64];
unsigned char numchars;
unsigned char catsym[8];
unsigned char catname[8][11];
unsigned char catinclude[8][8];
unsigned char numcategories;
dword numnodes;
} dawghdr;

I expect the size of the dawghdr structure to be 410 bytes. However,
on compiling this program with gcc 3.3.2 on linux, dawghdr uses 412
bytes. I've examined the memory space of this structure, and it seems
to me that 2 extra bytes appear between the numcategories and numnodes
members. Could anyone be kind enough to explain why this might be
happening?
Conpiler padding. Check your compiler's documentation
The program writes this structure to a disk file as a record, and I
later read this output file with a python script, but the script falls
over, as it fails to read the correct value of numnodes, since it has
no way of knowing about the 2 extra bytes.

Try writing(and reading) the structure element by element. Using that way
you don't care about padding.

[Martin Ambuhl]

Anand Buddhdev wrote:

....

I expect the size of the dawghdr structure to be 410 bytes. However,
on compiling this program with gcc 3.3.2 on linux, dawghdr uses 412
bytes.

....

For crying out loud, doesn't *anyone* check the FAQ before posting?

[Christian Haselbach]

Martin Ambuhl <ma*****@earthl ink.net> wrote:

For crying out loud, doesn't *anyone* check the FAQ before posting?

I did before I replied. :)

Ciao Chriss

[Rich Gibbs]

Anand Buddhdev said the following, on 07/21/04 07:19:

Hi everyone,

I'm a C newbie, so please be gentle. I have a program that defines the
following things:

typedef union
{
unsigned int I;
unsigned char b[4];
} dword;

/* Structure for record 0 of the DAWG. */
typedef struct
{
unsigned char magic[5];
unsigned char name[11];
unsigned char title[41];
unsigned char desc[41];
unsigned char author[41];
unsigned char extra[41];
unsigned char ch[64];
unsigned char numchars;
unsigned char catsym[8];
unsigned char catname[8][11];
unsigned char catinclude[8][8];
unsigned char numcategories;
dword numnodes;
} dawghdr;

I expect the size of the dawghdr structure to be 410 bytes. However,
on compiling this program with gcc 3.3.2 on linux, dawghdr uses 412
bytes. I've examined the memory space of this structure, and it seems
to me that 2 extra bytes appear between the numcategories and numnodes
members. Could anyone be kind enough to explain why this might be
happening?

The program writes this structure to a disk file as a record, and I
later read this output file with a python script, but the script falls
over, as it fails to read the correct value of numnodes, since it has
no way of knowing about the 2 extra bytes.

The compiler is allowed to insert padding bytes between elements of a
structure, in order to meet alignment restrictions of the
implementation. This is covered in the FAQ:
http://www.eskimo.com/~scs/C-faq/

The solution to your specific problem is going to be
implementation-dependent.

[OT]
Sometimes you can avoid the requirement for padding by placing the
structure elements in descending order of length. YMMV.

--
Rich Gibbs
rg****@alumni.p rinceton.edu

[Christopher Benson-Manica]

Darksun4 <da*******@yaho o.gr> spoke thus:

Conpiler padding

That would be structure padding, unless I'm not familiar with the
latest in plush compilers.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Gordon Burditt]

>I expect the size of the dawghdr structure to be 410 bytes. However,

Well, stop expecting that. The size of the structure is what the
compiler decides it will be (sizeof(struct dawghdr), not any
particular fixed integer). Including padding, if it feels like it.

Gordon L. Burditt

[Old Wolf]

Martin Ambuhl <ma*****@earthl ink.net> wrote:

Anand Buddhdev wrote:

...

I expect the size of the dawghdr structure to be 410 bytes. However,
on compiling this program with gcc 3.3.2 on linux, dawghdr uses 412
bytes.

...

For crying out loud, doesn't *anyone* check the FAQ before posting?

It's hard to find a specific issue in the online FAQ, except for the
small subset of issues which are easy to find, and also difficult to
find it in the flat text file if it isn't something you can easily
search for. The only time I've gotten something useful out of it was
when I read it from start to finish. Even then, I only remembered
things because I knew most of it already; for someone new to C
programming it may well be in one ear and out the other.

The HTML FAQ would be much more useful if it:
- had a single page with a hyperlinked summary-line of each entry
- had a text search facility
- was updated (I've heard the HTML ver is lagging behind the text ver)
- had an introductory page with the 20 or so most commonly asked
questions (in the format of all the hyperlinked summary lines at
the top, and all the answers at the bottom). It's a FAQ, not an EAQ
(Ever Asked Questions). Most of its entries are things that haven't
come up for years. It's annoying to wade through all these things.

(Note: this tirade was aimed at explaining why people ask FAQ questions
so often, it wasn't an attack on the FAQ maintainer).

[Sam Halliday]

Martin Ambuhl wrote:

Anand Buddhdev wrote:

I expect the size of the dawghdr structure to be 410 bytes. However,
on compiling this program with gcc 3.3.2 on linux, dawghdr uses 412
bytes.

For crying out loud, doesn't *anyone* check the FAQ before posting?

well, clearly not you either mr troll. and i quote:

"This is a large and heavy document, so don't assume that
everyone on the net has managed to read all of it in
detail, and please don't roll it up and thwack people
over the head with it just because they missed their
answer in it."
ftp://ftp.eskimo.com/u/s/scs/C-faq/faq.gz