padding bits...

[copx]

Hi, I remember hearing that the size of a struct can be bigger
than the sum of the sizes of its contents. Is that true?

For example let's say char is 1 byte and int is 4 byte in this case
and I've a struct defined like this:

struct pak_directory_entry_struct {
char file_name[56];
int file_position;
int file_length;
};

Is the size of this struct guaranteed to be 64 bytes
in this case or not?

copx

 

[infobahn]

Hi, I remember hearing that the size of a struct can be bigger
than the sum of the sizes of its contents. Is that true?
Yes.

For example let's say char is 1 byte

It is, by definition. But that byte may have more than 8 bits. The
number of bits making up a byte (and consequently the "width" of
a char) is CHAR_BIT, which must be >= 8.

and int is 4 byte in this case

Okay, for the sake of argument. (Of course, it might not be, but
it sounds like you know that already.)

and I've a struct defined like this:

struct pak_directory_entry_struct {
char file_name[56];
int file_position;
int file_length;
};

Is the size of this struct guaranteed to be 64 bytes
in this case or not?

No. The implementation may put an arbitrary number of padding bytes
after any (or even all!) of those members.

 

[Tom St Denis]

Hi, I remember hearing that the size of a struct can be bigger
than the sum of the sizes of its contents. Is that true?

For example let's say char is 1 byte and int is 4 byte in this case
and I've a struct defined like this:

struct pak_directory_entry_struct {
char file_name[56];
int file_position;
int file_length;
};

Is the size of this struct guaranteed to be 64 bytes
in this case or not?

It isn't. Depends on the platform. First off "int is 8 octets" on my
platform and yeah it could be padded.

If you're thinking of read/write'ing this verbatim to file ... don't.

Tom

 

[copx]

Hi, I remember hearing that the size of a struct can be bigger
than the sum of the sizes of its contents. Is that true?

For example let's say char is 1 byte and int is 4 byte in this case
and I've a struct defined like this:

struct pak_directory_entry_struct {
char file_name[56];
int file_position;
int file_length;
};

Is the size of this struct guaranteed to be 64 bytes
in this case or not?

It isn't. Depends on the platform. First off "int is 8 octets" on my
platform and yeah it could be padded.

If you're thinking of read/write'ing this verbatim to file ... don't.

Yep, that was the idea.

Thanks to everyone who replied,
copx

 

[Kevin Bracey]

In message <[email protected]>

Hi, I remember hearing that the size of a struct can be bigger
than the sum of the sizes of its contents. Is that true?

For example let's say char is 1 byte and int is 4 byte in this case
and I've a struct defined like this:

struct pak_directory_entry_struct {
char file_name[56];
int file_position;
int file_length;
};

Is the size of this struct guaranteed to be 64 bytes
in this case or not?

It's definitely not guaranteed. But in this particular case, the vast
majority of real-world implementations with 32-bit ints would have the
structure as 64 bytes long. An awful lot of real-world portable code relies
on cases like that (particularly from BSD Unix), so an implementation that
wilfully added padding would be unlikely to be accepted by the market.

A more likely implementation difference will be the endianness of the ints.
BSD code tends to rely on the structure layout for file/network interchange
but uses endianness swap functions to sort out shorts and ints.

It's safer if you wrote data structures out to disc manually, one byte at a
time. A handy subroutine would be a "fput_int32" function that outputs a
32-bit number as 4 bytes.

 

[Richard Bos]

In message <[email protected]>

Hi, I remember hearing that the size of a struct can be bigger
than the sum of the sizes of its contents. Is that true?

Yes.

For example let's say char is 1 byte and int is 4 byte in this case
and I've a struct defined like this:

struct pak_directory_entry_struct {
char file_name[56];
int file_position;
int file_length;
};

Is the size of this struct guaranteed to be 64 bytes
in this case or not?

It's definitely not guaranteed. But in this particular case, the vast
majority of real-world implementations with 32-bit ints would have the
structure as 64 bytes long.

Conversely, though, if file_name were 55 chars rather than 56, there
would almost certainly (but again, not guaranteed) be a padding byte
between it and file_position, and the size of the struct would probably
still be 64 bytes.

Richard

 

[Neil Kurzman]

Hi, I remember hearing that the size of a struct can be bigger
than the sum of the sizes of its contents. Is that true?

For example let's say char is 1 byte and int is 4 byte in this case
and I've a struct defined like this:

struct pak_directory_entry_struct {
char file_name[56];
int file_position;
int file_length;
};

Is the size of this struct guaranteed to be 64 bytes
in this case or not?

copx

The compiler may add bytes to align the data with what ever the CPU
likes best. 1,2,4,or 8 bytes
Odd spacing would slow down the memory fetches. If you need specific
packing Look up the non-standard structure packing options for you
compiler.

 

[Peter Nilsson]

The compiler may add bytes to align the data with what ever the
CPU likes best. 1,2,4,or 8 bytes

Compilers can add padding for reasons other than individual member
alignment requirements.

 

[Gordon Burditt]

Hi, I remember hearing that the size of a struct can be bigger

than the sum of the sizes of its contents. Is that true?
Yes.


For example let's say char is 1 byte

In C, this is true by definition, but if you meant char is one Disk
Manufacturer's Byte, that might also be true.

and int is 4 byte in this case

It might be, but there are plenty of exceptions to this, and there
will probably be a growing number where int is 8 Disk Manufacturer's
Bytes.

and I've a struct defined like this:

struct pak_directory_entry_struct {
char file_name[56];
int file_position;
int file_length;
};

Is the size of this struct guaranteed to be 64 bytes
in this case or not?

The size of a structure is never guaranteed to be exactly anything and
it is not guaranteed that one copy of it will fit on your hard disk
(if your system has one). Yes, it could have 700GBytes of padding.
Not that such an implementation would sell well.

If you are considering moving such a file across systems, consider
converting it to a text format instead:

fprintf(pak, "%ld %ld %s\n", pdep->file_position, pdep->file_length,
pdep->file_name);

Assuming, of course, that legal file names can't contain newlines (something
not guaranteed on UNIX systems).

Gordon L. Burditt