sizeof and padding
Kenneth Brody
sizeof is guaranteed to include any padding bytes that are added at the
end of the struct?
For example, suppose I am on a platform with 32-bit alignment needed on
32-bit entities, and I have the following struct:
struct foo
{
MY_32_BIT_TYPE a;
char b;
};
On such a system, an array of struct foo would each be padded to 8 bytes,
but theoretically, a single struct foo could fit in 5 bytes.
Am I correct that sizeof(struct foo) is guaranteed to include the padding
bytes and (in this instance) return 8?
--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody at spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
--
comp.lang.c.moderated - moderation address: cl...@plethora.net
Herbert Rosenau
<kenbro...@spamcop.net> wrote:
> I have a question regarding sizeof and struct padding. Am I correct that
> sizeof is guaranteed to include any padding bytes that are added at the
> end of the struct?
Yes. sizeof gives always the same number of bytes for an type. This
number may differ on different implementations but not inside one.
--
Tschau/Bye
Herbert
Visit http://www.ecomstation.de the home of german eComStation
Francis Glassborow
<kenbro...@spamcop.net> writes
>I have a question regarding sizeof and struct padding. Am I correct that
>sizeof is guaranteed to include any padding bytes that are added at the
>end of the struct?
>
>For example, suppose I am on a platform with 32-bit alignment needed on
>32-bit entities, and I have the following struct:
>
> struct foo
> {
> MY_32_BIT_TYPE a;
> char b;
> };
>
>On such a system, an array of struct foo would each be padded to 8 bytes,
>but theoretically, a single struct foo could fit in 5 bytes.
>
>Am I correct that sizeof(struct foo) is guaranteed to include the padding
>bytes and (in this instance) return 8?
Yes. The sizeof a type must be such that the adjacency requirement of
raw arrays is met without breaking any alignment requirements. I.e. it
is required that:
sizeof(mytype[n]) == n * sizeof(mytype);
That implies that any padding required to satisfy alignment requirements
be part of the object.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
Dan Pop
>I have a question regarding sizeof and struct padding. Am I correct that
>sizeof is guaranteed to include any padding bytes that are added at the
>end of the struct?
>
>For example, suppose I am on a platform with 32-bit alignment needed on
>32-bit entities, and I have the following struct:
>
> struct foo
> {
> MY_32_BIT_TYPE a;
> char b;
> };
>
>On such a system, an array of struct foo would each be padded to 8 bytes,
>but theoretically, a single struct foo could fit in 5 bytes.
>
>Am I correct that sizeof(struct foo) is guaranteed to include the padding
>bytes and (in this instance) return 8?
You can get the answer yourself, if you consider that you can build arrays
of struct type and pointer arithmetic on the array elements must work as
advertised.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
xarax
news:clcm-2004...@plethora.net...
> I have a question regarding sizeof and struct padding. Am I correct that
> sizeof is guaranteed to include any padding bytes that are added at the
> end of the struct?
>
> For example, suppose I am on a platform with 32-bit alignment needed on
> 32-bit entities, and I have the following struct:
>
> struct foo
> {
> MY_32_BIT_TYPE a;
> char b;
> };
>
> On such a system, an array of struct foo would each be padded to 8 bytes,
> but theoretically, a single struct foo could fit in 5 bytes.
>
> Am I correct that sizeof(struct foo) is guaranteed to include the padding
> bytes and (in this instance) return 8?
sizeof(thing) always returns the full size to account for
alignment requirements. Padding is an effect of alignment
requirements.
You can determine the alignment of a type by using a simple
macro:
#define alignof(type) (sizeof(struct{type a;char b;})-sizeof(struct{type a;}))
The "type" operand is the simple name of a type (a typedef
name works best).
Alignment is important for a variety of reasons, most of
which even seasoned programmers do not grasp. Before disabling
alignment (implicit padding), be sure that you understand what
you are doing and the implications of using misaligned data.
--
----------------------------
Jeffrey D. Smith
Farsight Systems Corporation
24 BURLINGTON DRIVE
LONGMONT, CO 80501-6906
http://www.farsight-systems.com
z/Debug debugs your Systems/C programs running on IBM z/OS for FREE!
Jerry Feldman
Kenneth Brody <kenbro...@spamcop.net> wrote:
> I have a question regarding sizeof and struct padding. Am I correct
> that sizeof is guaranteed to include any padding bytes that are added
> at the end of the struct?
>
> For example, suppose I am on a platform with 32-bit alignment needed
> on 32-bit entities, and I have the following struct:
>
> struct foo
> {
> MY_32_BIT_TYPE a;
> char b;
> };
>
> On such a system, an array of struct foo would each be padded to 8
> bytes, but theoretically, a single struct foo could fit in 5 bytes.
>
> Am I correct that sizeof(struct foo) is guaranteed to include the
> padding bytes and (in this instance) return 8?
>
>From ANSI C89 3.5.2.1.15:"There may also be unnamed padding at the end
of a structure or union, as necessary to achieve the appropriate
alignment where the structure or union to be an element of an array".
You might find that on some platforms, a struct must start on a 64 bit
boundary, so the minimum size of a struct might be a full 8 bytes such
that:
struct foo {
char a;
}; might also be 8 bytes. Think of an array of struct foo. Each instance
must start on the proper alignment for the respective
--
Jerry Feldman <gaf-nospam-at-blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
Hans-Bernhard Broeker
> I have a question regarding sizeof and struct padding. Am I correct that
> sizeof is guaranteed to include any padding bytes that are added at the
> end of the struct?
In a nutshell: yes. Padding bytes are considered part of the
structure itself, so yes, they will be accounted for by its sizeof().
--
Hans-Bernhard Broeker (bro...@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Douglas A. Gwyn
> I have a question regarding sizeof and struct padding. Am I correct that
> sizeof is guaranteed to include any padding bytes that are added at the
> end of the struct?
Yes.
Barry Schwarz
wrote:
>I have a question regarding sizeof and struct padding. Am I correct that
>sizeof is guaranteed to include any padding bytes that are added at the
>end of the struct?
>
>For example, suppose I am on a platform with 32-bit alignment needed on
>32-bit entities, and I have the following struct:
>
> struct foo
> {
> MY_32_BIT_TYPE a;
> char b;
> };
>
>On such a system, an array of struct foo would each be padded to 8 bytes,
>but theoretically, a single struct foo could fit in 5 bytes.
>
>Am I correct that sizeof(struct foo) is guaranteed to include the padding
>bytes and (in this instance) return 8?
>
The first half of your assertion is correct. sizeof does include the
padding. In your example, it is guaranteed to return a multiple of 4
that is larger than 5. 8 is possible but 12 would not violate the
standard.
<<Remove the del for email>>
Jack Klein
> I have a question regarding sizeof and struct padding. Am I correct that
> sizeof is guaranteed to include any padding bytes that are added at the
> end of the struct?
>
> For example, suppose I am on a platform with 32-bit alignment needed on
> 32-bit entities, and I have the following struct:
>
> struct foo
> {
> MY_32_BIT_TYPE a;
> char b;
> };
>
> On such a system, an array of struct foo would each be padded to 8 bytes,
> but theoretically, a single struct foo could fit in 5 bytes.
>
> Am I correct that sizeof(struct foo) is guaranteed to include the padding
> bytes and (in this instance) return 8?
This has nothing in particular to do with the sizeof operator, and
more to do with the actual size of the object.
Any object, including structures, may be placed in an array, and there
is no padding in between the elements of an array. So if an object
has an alignment requirement, its size must also be a multiple of that
value.
So on an architecture that requires alignment of struct foo on a 32
bit alignment, the size of the structure will be a multiple of 32
bits.
That does not mean, however, that the structure will have a size of 8,
since there are platforms where chars have more than 8 bits. There
are implementations where sizeof(struct foo) would be 4 or 2.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
Ravi Uday
> I have a question regarding sizeof and struct padding. Am I correct that
> sizeof is guaranteed to include any padding bytes that are added at the
> end of the struct?
Implementation defined. But in most cases YES.
>
> For example, suppose I am on a platform with 32-bit alignment needed on
> 32-bit entities, and I have the following struct:
>
> struct foo
> {
> MY_32_BIT_TYPE a;
> char b;
> };
>
> On such a system, an array of struct foo would each be padded to 8 bytes,
> but theoretically, a single struct foo could fit in 5 bytes.
>
> Am I correct that sizeof(struct foo) is guaranteed to include the padding
> bytes and (in this instance) return 8?
>
Guaranteed ! Well no, check for your compiler documentation. By using
*pragmas* you could verify and change the padding inserted by compiler
Michel Bardiaux
> I have a question regarding sizeof and struct padding. Am I correct that
> sizeof is guaranteed to include any padding bytes that are added at the
> end of the struct?
>
> For example, suppose I am on a platform with 32-bit alignment needed on
> 32-bit entities, and I have the following struct:
>
> struct foo
> {
> MY_32_BIT_TYPE a;
> char b;
> };
>
> On such a system, an array of struct foo would each be padded to 8 bytes,
> but theoretically, a single struct foo could fit in 5 bytes.
>
> Am I correct that sizeof(struct foo) is guaranteed to include the padding
> bytes and (in this instance) return 8?
>
Yes.
--
Michel Bardiaux
Peaktime Belgium S.A. Bd. du Souverain, 191 B-1160 Bruxelles
Tel : +32 2 790.29.41
kgold
"the amount of memory that would be occupied ... including any
internal or trailing padding".
Kenneth Brody <kenbro...@spamcop.net> writes:
> I have a question regarding sizeof and struct padding. Am I correct that
> sizeof is guaranteed to include any padding bytes that are added at the
> end of the struct?
>
> For example, suppose I am on a platform with 32-bit alignment needed on
> 32-bit entities, and I have the following struct:
>
> struct foo
> {
> MY_32_BIT_TYPE a;
> char b;
> };
>
> On such a system, an array of struct foo would each be padded to 8 bytes,
> but theoretically, a single struct foo could fit in 5 bytes.
>
> Am I correct that sizeof(struct foo) is guaranteed to include the padding
> bytes and (in this instance) return 8?
--
Dave Neary
On 28 Jun 2004 05:26:10 GMT, Kenneth Brody said:
> I have a question regarding sizeof and struct padding. Am I correct that
> sizeof is guaranteed to include any padding bytes that are added at the
> end of the struct?
Yes. sizeof is the number of bytes that get skipped when you add one to
a pointer to an object of that type.
So
struct filip {
char c;
double d;
char c
} ;
int main (void)
{
struct filip *a = malloc(4 * sizeof *a);
/* *a is guaranteed big enough to store 4 struct filips
* and we have allocated 4 * sizeof (struct filip) char-sized
* blocks, therefore, sizeof an object includes padding
*/
free(a);
return 0;
}
> Am I correct that sizeof(struct foo) is guaranteed to include the padding
> bytes and (in this instance) return 8?
structs usually align on word boundaries, but I don't believe they have
to, so you cannot assume a given return value from sizeof in this case.
Cheers,
Dave.
--
David Neary,
E-Mail: bolsh at gimp dot org
Work e-mail: d dot neary at phenix dot fr
CV: http://dneary.free.fr/CV/
Kenneth Brody
>
> In <clcm-2004...@plethora.net> Kenneth Brody <kenbro...@spamcop.net> writes:
>
> >I have a question regarding sizeof and struct padding. Am I correct that
> >sizeof is guaranteed to include any padding bytes that are added at the
> >end of the struct?
> You can get the answer yourself, if you consider that you can build arrays
> of struct type and pointer arithmetic on the array elements must work as
> advertised.
Well, it certainly made sense that the only way it could work in an array
is if sizeof included those padding bytes, but that also seems to imply
that a single entity of that type must also include the same padding bytes
as would be necessary if it were in an array.
For example, re-using my previous struct:
struct foo
{
MY_32_BIT_TYPE a;
char b;
};
Assuming 32-bit alignment on an 8-bit-char system sizeof(struct foo) would
be expected to be 8. (Yes, I know this is implementation defined, but I
have to pick some reasonable numbers for an example implementation.) But,
theoretically, the above could be stored in 5 bytes if the surrounding data
only needed 8-bit alignment, as in:
char a;
struct foo b;
char c;
I assume that, if the implementation chooses to store these variables in
memory in the order in which they're listed above, that "b" would still
need to be padded to 8 bytes, and therefore "c" would be placed with 32-bit
alignment.
--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody at spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Dave Neary
I guess self-correction of typos is OK?
In article <clcm-2004...@plethora.net>, Dave Neary wrote:
#include <stdlib.h>
> struct filip {
> char c;
char c1;
> double d;
> char c
char c2;
> } ;
Small corrections, but ne'ertheless...
Cheers,
Dave.
Dan Pop
>Dan Pop wrote:
>>
>> In <clcm-2004...@plethora.net> Kenneth Brody <kenbro...@spamcop.net> writes:
>>
>> >I have a question regarding sizeof and struct padding. Am I correct that
>> >sizeof is guaranteed to include any padding bytes that are added at the
>> >end of the struct?
>[...]
>> You can get the answer yourself, if you consider that you can build arrays
>> of struct type and pointer arithmetic on the array elements must work as
>> advertised.
>
>Well, it certainly made sense that the only way it could work in an array
>is if sizeof included those padding bytes, but that also seems to imply
>that a single entity of that type must also include the same padding bytes
>as would be necessary if it were in an array.
The padding is decided at the time the structure is defined. The compiler
doesn't know how the structure will be used, so it must assume the
possibility of having arrays of it and, therefore, include the trailing
padding. Once the trailing padding has been included in the structure
layout, the sizeof operator must reflect it.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
Paul_Huang
Below is my sample code:
***************************************************
#include <iostream>
using namespace std;
#include <Windows.h>
#pragma pack( push )
#pragma pack( 2 )
struct GroupEntry2
{
BYTE bWidth; // Width, in pixels, of the image
BYTE bHeight; // Height, in pixels, of the image
BYTE bColorCount; // Number of colors in image (0 if
>=8bpp)
BYTE bReserved; // Reserved
WORD wPlanes; // Color Planes
WORD wBitCount; // Bits per pixel
DWORD dwBytesInRes; // how many bytes in this resource?
};
struct DllGroupEntry2 : GroupEntry2
{
WORD nID; // the ID
};
struct FileGroupEntry2 : GroupEntry2
{
DWORD dwImageOffset;
};
struct Group2
{
WORD zero;
WORD idType; // Resource type (1 for icons, 2 for cursors)
WORD idCount; // How many images?
};
#pragma pack( pop )
struct GroupEntry
{
BYTE bWidth; // Width, in pixels, of the image
BYTE bHeight; // Height, in pixels, of the image
BYTE bColorCount; // Number of colors in image (0 if
>=8bpp)
BYTE bReserved; // Reserved
WORD wPlanes; // Color Planes
WORD wBitCount; // Bits per pixel
DWORD dwBytesInRes; // how many bytes in this resource?
};
struct DllGroupEntry : GroupEntry
{
WORD nID; // the ID
};
struct FileGroupEntry : GroupEntry
{
DWORD dwImageOffset;
};
struct Group
{
WORD zero;
WORD idType; // Resource type (1 for icons, 2 for cursors)
WORD idCount; // How many images?
};
void main() {
cout<<"sizeof GroupEntry2 = "<<sizeof(GroupEntry2)<<endl;
cout<<"sizeof DllGroupEntry2 = "<<sizeof(DllGroupEntry2)<<endl;
cout<<"sizeof FileGroupEntry2 = "<<sizeof(FileGroupEntry2)<<endl;
cout<<"sizeof Group2 = "<<sizeof(Group2)<<endl;
cout<<"sizeof GroupEntry = "<<sizeof(GroupEntry)<<endl;
cout<<"sizeof DllGroupEntry = "<<sizeof(DllGroupEntry)<<endl;
cout<<"sizeof FileGroupEntry = "<<sizeof(FileGroupEntry)<<endl;
cout<<"sizeof Group = "<<sizeof(Group)<<endl;
}
**************************************************
I compiled and run the code. below is the output:
--------------------------------------------------
sizeof GroupEntry2 = 12
sizeof DllGroupEntry2 = 14
sizeof FileGroupEntry2 = 16
sizeof Group2 = 6
sizeof GroupEntry = 12
sizeof DllGroupEntry = 16
sizeof FileGroupEntry = 16
sizeof Group = 6
-------------------------------------------
My environment is: Windows XP on Pentium 4, VC++ 6.0.
My question is:
1. Why the size of DllGroupEntry is 16? Is it due to the memory alignment
to 4 bytes?
2. If the answer to the above question is "true", why the size of Group is
still 6 instead of 8? Why the structure of Group is not aligned to 8
bytes? Why not insert 2 bytes into Group for the memory alignment?
Thanks
CBFalconer
>
> OK, I tried it with a piece of sample code and get some weird results.
> Below is my sample code:
> ***************************************************
> #include <iostream>
> using namespace std;
> #include <Windows.h>
Each line is an error in C. Maybe you want c.l.c++?
.... snip stuff in unknown language ...
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Barry Schwarz
wrote:
>OK, I tried it with a piece of sample code and get some weird results.
>Below is my sample code:
>***************************************************
>#include <iostream>
>using namespace std;
snip
>My question is:
>1. Why the size of DllGroupEntry is 16? Is it due to the memory alignment
>to 4 bytes?
>2. If the answer to the above question is "true", why the size of Group is
>still 6 instead of 8? Why the structure of Group is not aligned to 8
>bytes? Why not insert 2 bytes into Group for the memory alignment?
>
Since your code is C++, not C, and your questions are compiler
specific, you might have better luck in one of the microsoft vc
newsgroups.
<<Remove the del for email>>
Brian Inglis
<paul.h...@gmail.com> wrote:
Somewhat OT as this is C++ code in a C group, but what the hay!
Assuming sizeof BYTE == 1 WORD == 2 DWORD == 4.
>My question is:
>1. Why the size of DllGroupEntry is 16? Is it due to the memory alignment
>to 4 bytes?
As the DWORD member requires alignment on 4 byte boundaries, the
structure requires alignment on 4 byte boundaries, so that the DWORD
member in an array of structures is also aligned on 4 byte boundaries.
>2. If the answer to the above question is "true", why the size of Group is
>still 6 instead of 8? Why the structure of Group is not aligned to 8
>bytes? Why not insert 2 bytes into Group for the memory alignment?
Because WORD members only require alignment on 2 byte boundaries.
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Brian....@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
wim.yedema
Sorry to dredge up such an old thread, but I felt there was not a satisfactory answer to this question yet.
The problem I have with the quote from the standard is the word "may". I would like someone to point out the paragraph in the standard that guarantees that:
sizeof(struct foo)==sizeof(struct foo[1])
I haven't been able to find it. I guess it must hold because otherwise things like malloc(n*sizeof(struct foo)) are actually broken, but I like proof.
Wim Yedema
--
comp.lang.c.moderated - moderation address: cl...@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Francis Glassborow
Sometimes things are implicit, as in this case. Given two choices if one
breaks the Standard elsewhere and the other does not then there is no
real choice. If Standards had to dot every i and cross every t and make
everything explicit there would be no trees left :)
James Kuyper
> On Thursday, July 1, 2004 9:04:38 PM UTC+2, Jerry Feldman wrote:
>> On 28 Jun 2004 05:26:10 GMT
>> Kenneth Brody <kenbro...@spamcop.net> wrote:
>>
>>> I have a question regarding sizeof and struct padding. Am I correct
>>> that sizeof is guaranteed to include any padding bytes that are added
>>> at the end of the struct?
>>>
>>> For example, suppose I am on a platform with 32-bit alignment needed
>>> on 32-bit entities, and I have the following struct:
>>>
>>> struct foo
>>> {
>>> MY_32_BIT_TYPE a;
>>> char b;
>>> };
>>>
>>> On such a system, an array of struct foo would each be padded to 8
>>> bytes, but theoretically, a single struct foo could fit in 5 bytes.
>>>
>>> Am I correct that sizeof(struct foo) is guaranteed to include the
>>> padding bytes and (in this instance) return 8?
Google groups shows 21 messages belonging to the original thread. To my
surprise, not a single one of them bothered to quote the section of the
standard that very directly and clearly addresses this question:
6.5.3.4p3: (describing the sizeof operator): "When applied to an operand
that has structure or union type, the result is the total number of
bytes in such an object, including internal and trailing padding."
>> >From ANSI C89 3.5.2.1.15:"There may also be unnamed padding at the end
>> of a structure or union, as necessary to achieve the appropriate
>> alignment where the structure or union to be an element of an array".
>> You might find that on some platforms, a struct must start on a 64 bit
>> boundary, so the minimum size of a struct might be a full 8 bytes such
>> that:
>> struct foo {
>> char a;
>> }; might also be 8 bytes. Think of an array of struct foo. Each instance
>> must start on the proper alignment for the respective
>
> Sorry to dredge up such an old thread, but I felt there was not a satisfactory answer to this question yet.
>
> The problem I have with the quote from the standard is the word "may". I would like someone to point out the paragraph in the standard that guarantees that:
> sizeof(struct foo)==sizeof(struct foo[1])
>
> I haven't been able to find it. I guess it must hold because otherwise things like malloc(n*sizeof(struct foo)) are actually broken, but I like proof.
6.5.3.4p2: "The sizeof operator yields the size (in bytes) of its
operand, which may be an expression or the parenthesized name of a type.
The size is determined from the type of the operand."
Key point: the size depends only upon the type, and not upon the context
in which the type appears.
6.2.5p20: "An array type describes a contiguously allocated nonempty set
of objects with a particular member object type, called the element
type.36)"
The word "contiguous" rules out gaps between the objects. The fact that
an array type describes ONLY the set of objects that make it up, means
that if an implementation chooses to put padding before or after the
array, such padding is NOT part of what the array type describes.
Therefore, sizeof would not include such padding. An array of length 1
describes only a single object of the element type, and must therefore
have a size that is the same as that of the element type.
--
James Kuyper
Kenneth Brody
[...]
>> From ANSI C89 3.5.2.1.15:"There may also be unnamed padding at the end
>> of a structure or union, as necessary to achieve the appropriate
>> alignment where the structure or union to be an element of an array".
> Sorry to dredge up such an old thread, but I felt there was not
> a satisfactory answer to this question yet.
>
> The problem I have with the quote from the standard is the word
> "may". I would like someone to point out the paragraph in the
> standard that guarantees that:
> sizeof(struct foo)==sizeof(struct foo[1])
>
> I haven't been able to find it. I guess it must hold because
> otherwise things like malloc(n*sizeof(struct foo)) are actually
> broken, but I like proof.
If "sizeof(struct foo[N])" were not exactly the same value as
"N*sizeof(struct foo)", then that would mean the array in the first example
were to have padding bytes _between_ elements, which is forbidden by
6.2.5p20: (emphasis mine)
> An array type describes a *contiguously* allocated nonempty set of
> objects with a particular member object type, called the element
> type.
--
Kenneth Brody