-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
1) what makes you believe that an int is not more than 4 bytes long?
2rd block: s1+pad = 4 bytes
2) what makes you believe that a short int is not more than 4 bytes
long?
3rd block" c+pad = 4 bytes
4th block: d+ pad = 4 bytes
3) what makes you believe that two char variables need padding between
them?
4) what makes you believe that a char is not more than 4 bytes long?
5th block: j+pad = 4 bytes
Are you sure? I don't think that, given the generic nature of the
question, you can say that this value is correct, even if you did have
the correct padding lengths.
64 bit Machine
----------------
1st block: i + pad = 8 byte
2nd block: si + pad = 8 byte
3rd block: c + pad = 8 byte
4ht block: d + pad = 8 byte
5ht block: j + pad = 8 byte
Same questions wrt assumed length, alignment.
Language: Arabic Bulgarian Catalan Chinese (Simplified) Chinese
(Traditional) Croatian Czech Danish Dutch English / Automatic Estonian
Finnish French German Greek Hebrew Hungarian Icelandic Indonesian
Italian Japanese Korean Latvian Lithuanian Norwegian Polish Portuguese
Romanian Russian Serbian Slovak Slovenian Spanish Swedish Turkish
what does this have to do with anything?
Same comment wrt the value and padding.
Why would it be differnt from the previous example?
Data element sizes and alignment requirements might be different between
the different platforms.
would explain how to use sizeof to determine that as well?
what is POD and ALIGNED ADDRESS?
what is POD?
I don't know what "POD" is. Did you mean "PAD"?
FWIW, there's no /absolute/ answer to your question. The answer will
depend on more than just whether a platform is "32 bit" or "64 bit"
(whatever /that/ means). The answer depends primarily on the QoI of the
compiler /and/ the underlying platform requirements.
A simplistic answer is that the C data types are generally matched (by
the compiler) to native hardware datatypes, and it is the compiler's job
to make sure that the requirements of those hardware datatypes are met.
If, for instance, the hardware dictates that all datatypes consist of
one or more 24-bit entities, and all datatypes must be aligned on a
32-bit boundary, then the compiler must match it's sizing and placement
of the C datatypes to these rules. The writer of the C compiler is free
to select how the compiler will map C datatypes into these rules. This
may result (in this instance) in
- - char being mapped into a single 24-bit machine entitiy
- - short int and int being mapped into a 48-bit machine entity
(consisting of two 24-bit machine entities)
- - long int being mapped into a single 72-bit machine entity
(consisting of three 24-bit machine entities)
The architect of the C compiler could have mapped long int into a 96-bit
entity instead of a 72-bit entity; it was his choice of how the mapping
was to work.
Note that, even with this mapping, sizeof(char) is still 1 (even though
char is 24-bits long), while sizeof(short int) would be 2, and
sizeof(long int) would be 3.
Now, a structure such as
struct {
int a;
long b;
char c;
};
would have to have it's elements positioned (because of the alignment
rules) on 32-bit boundaries. The compiler would be 'smart' enough to
start the first element on such a boundary, and would have to arrange
placement of the remaining elements to match the alignment rule.
So, it would, under the covers make the following sorts of decisions
- place 48-bit int on 32-bit boundary
- insert 16-bit padding to restore alignment to 32-bit boundary
- place 72-bit long on 32-bit boundary
- insert 24-bit padding to restore alignment to 32-bit boundary
- place 24-bit char on 32-bit boundary
Now, most compilers don't have this sort of complexity to deal with, but
/some/ do. And do it in "32 bit" or "64 bit" environments. If you lurk a
bit, you'll run into at least one regular here who works in C on 64bit
DSPs, on which /all/ C datatypes are 64-bit machine entities, including
/char/ entities.
- --
Lew Pitcher, IT Consultant, Enterprise Data Systems
Enterprise Technology Solutions, TD Bank Financial Group
(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
iD8DBQFB7oYFagVFX4UWr64RAlejAKDvcUaJmupc+FFd8HRIIuIlb0XFjACcDd6O
USuw+bnZ4bntDbsOzfg4xsY=
=KkfS
-----END PGP SIGNATURE-----
