By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,024 Members | 2,027 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,024 IT Pros & Developers. It's quick & easy.

alignment revisited

P: n/a

2)
struct B
{
int i;
short int si;
char c;
char d;
int j;
};

32 bit machine
--------------
1st block: i+pad = 4 bytes
2rd block: s1+pad = 4 bytes
3rd block" c+pad = 4 bytes
4th block: d+ pad = 4 bytes
5th block: j+pad = 4 bytes
---------------------------------------
TOTAL: 20 bytes

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

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


---------------------------------
TOTAL: = 40 bytes
Why would it be differnt from the previous example?
would explain how to use sizeof to determine that as well?
what is POD and ALIGNED ADDRESS?
what is POD?
Thanks

Nov 14 '05 #1
Share this Question
Share on Google+
17 Replies


P: n/a
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

puzzlecracker wrote:
2)
struct B
{
int i;
short int si;
char c;
char d;
int j;
};

32 bit machine
--------------
1st block: i+pad = 4 bytes


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
---------------------------------------
TOTAL: 20 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?
---------------------------------
TOTAL: = 40 bytes

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+FFd8HRIIu Ilb0XFjACcDd6O
USuw+bnZ4bntDbsOzfg4xsY=
=KkfS
-----END PGP SIGNATURE-----
Nov 14 '05 #2

P: n/a
puzzlecracker wrote:
.... snip ...
Why would it be differnt from the previous example?

would explain how to use sizeof to determine that as well?
what is POD and ALIGNED ADDRESS?

what is POD?


You have been told how to generate a proper reply on google (but
see my sig again). You have just started a new thread with a
different subject, so that nobody knows what, if anything, you are
talking about. If you don't care to be clear, we don't care to
help.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

Nov 14 '05 #3

P: n/a
"puzzlecracker" <ir*********@gmail.com> wrote:
2)
struct B
{
int i;
short int si;
char c;
char d;
int j;
};


32 bit machine
--------------
1st block: i+pad = 4 bytes
2rd block: s1+pad = 4 bytes
3rd block" c+pad = 4 bytes
4th block: d+ pad = 4 bytes
5th block: j+pad = 4 bytes
---------------------------------------
TOTAL: 20 bytes

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


You don't know any of this, even with your assumptions of N-bit
"machine". In fact, they're probably wrong.
Language: Arabic Bulgarian Catalan Chinese (Simplified) Chinese
What the dickens has that got to do with the price of fish?
Why would it be differnt from the previous example?
Because, as many people have been trying to get you to accept, the size
of objects and the padding of structure are _compiler-dependent_. It is
not possible to simply state "64-bit system" and then presume you know
all about the implementation you use.
would explain how to use sizeof to determine that as well?
You cannot use sizeof to determine the internal stucture (hah) of a
structure. You use sizeof to determine the size, surprise again, of any
object or object type, including any complete struct type. To determine
the size of a struct, use sizeof in the usual way. If you don't know
what the usual way to use sizeof _is_, you really need to open a
textbook on C. I recommend K&R 2.
what is POD?


I'm beginning to suspect a pod is what you may have come out of. A pod
from planet Zog.

Richard
Nov 14 '05 #4

P: n/a
"puzzlecracker" <ir*********@gmail.com> writes:
[...]
what is POD?


I *think* POD is a C++ term that means "plain old data". If that's
what your asking about, this isn't the place to ask it. Try the C++
FAQ, a C++ textbook, or a Google search. (I don't know where the C++
FAQ is; Google does.) As a last resort, try comp.lang.c++.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #5

P: n/a
Unbelievable! Ok I know it is platform dependent; stop reminding it
to me. What I am looking for is rules applied that should be
independent of platform in question. Let's agree on a standard,
elaborate on the rules relevent to it.
thanks

Nov 14 '05 #6

P: n/a
"puzzlecracker" <ir*********@gmail.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.com...
Unbelievable!
Many folks have trouble believing facts.
Ok I know it is platform dependent;
Your continual posts about this lead me to believe otherwise.
stop reminding it
to me.
Sorry, we won't, if you keep asking about it.

The C language is platform-neutral, which is why issues
which are not are not topical here.
What I am looking for is rules applied that should be
independent of platform in question.
There aren't any (for what you're asking about). Platforms
are different. That just the way it is.
Let's agree on a standard,
elaborate on the rules relevent to it.


Standards that pertain to multiple platforms necessarily
cannot include issues other than what those platforms have
in common. Not every feature of each platform exists on all
of them.

Why you seem to fail to grasp this is beyond me.

-Mike
Nov 14 '05 #7

P: n/a
On 19 Jan 2005 10:09:10 -0800, "puzzlecracker" <ir*********@gmail.com>
wrote:
Unbelievable! Ok I know it is platform dependent; stop reminding it
to me. What I am looking for is rules applied that should be
independent of platform in question. Let's agree on a standard,
elaborate on the rules relevent to it.
thanks


I'm kill-filing you until someone indicates that you've learned how to
post. That will probably be a long time, since you've already had
ample opportunity and instruction. Bye, now.

--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 14 '05 #8

P: n/a
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

puzzlecracker wrote:
Unbelievable! Ok I know it is platform dependent; stop reminding it
to me. What I am looking for is rules applied that should be
independent of platform in question. Let's agree on a standard,
elaborate on the rules relevent to it.

Sure.

The rules are simple:
- - sizeof() will give you the size (in char units) of any single datatype

- - CHAR_BITS is the number of bits in the char datatype

- - the width of the C datatypes are not defined other than as certain
minimum widths. The documented minimums can be found in the C
standard.

- - the compiler must pad data elements in a structure with whatever
padding is necessary to align those data elements to boundaries
dictated by the requirements of the compiler and it's environment.

Everything else is implementation dependant.

- --

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)

iD8DBQFB7qrpagVFX4UWr64RAr7+AKDPBdgC5OBCpykTPxnxh0 UfgMIH/wCgi5+w
IAJVxeFhPn34WrS6up/dIrQ=
=JcCn
-----END PGP SIGNATURE-----
Nov 14 '05 #9

P: n/a
puzzlecracker wrote:
Unbelievable! Ok I know it is platform dependent; stop reminding it
to me. What I am looking for is rules applied that should be
independent of platform in question. Let's agree on a standard,
elaborate on the rules relevent to it.
thanks


What exactly is your problem with posting properly through google? It
takes EXACTLY one extra click. I know this, because I'm currently using
it to post until such time as they fix our outgoing message problem.
Is it your goal to see how many killfiles you can get in?


Brian

Nov 14 '05 #10

P: n/a
puzzlecracker wrote:

Unbelievable! Ok I know it is platform dependent; stop reminding it
to me. What I am looking for is rules applied that should be
independent of platform in question. Let's agree on a standard,
elaborate on the rules relevent to it.


We have agreed on a standard. It says that you will quote enough
of the article to which you are replying to supply an adequate
context, indicate attributions, and snip the quoted portions not
germane to your reply. You insist on ignoring that standard even
though told how to adhere to it with the ridiculous google
interface.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Nov 14 '05 #11

P: n/a
"puzzlecracker" <ir*********@gmail.com> writes:
Unbelievable! Ok I know it is platform dependent; stop reminding it
to me. What I am looking for is rules applied that should be
independent of platform in question. Let's agree on a standard,
elaborate on the rules relevent to it.
thanks


What's unbelievable?

Are you asking us for a solution to the problem, or for a clearer way
to state the problem? If you want a clearer problem statement, you'll
probably have to do it yourself. If you can give us a clear and
unambiguous problem statement, we might be interested in playing with
it. If not -- well, I can't speak for anyone else, but frankly it's
not worth my time.

And please post properly. You've been told repeatedly how to do this.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #12

P: n/a
In article <dC*********************@news20.bellglobal.com>,
Lew Pitcher <Le*********@td.com> wrote:
4) what makes you believe that a char is not more than 4 bytes long?


I thought that the standard defines/requires that sizeof(char) is one?
Nov 14 '05 #13

P: n/a
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rudolf wrote:
In article <dC*********************@news20.bellglobal.com>,
Lew Pitcher <Le*********@td.com> wrote:

4) what makes you believe that a char is not more than 4 bytes long?

I thought that the standard defines/requires that sizeof(char) is one?


Smarta** :-)

Read my question in context. The OP is counting machine bytes (octets), not C
bytes, and I answered in the same context.

- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB7x71agVFX4UWr64RAu8vAKCF6aQtRvVaPPEv735Vo1 APyUeVgwCg5+01
aa8GjEdG2Rh4BO1H9MrW7qU=
=GIGw
-----END PGP SIGNATURE-----
Nov 14 '05 #14

P: n/a
Lew Pitcher <lp******@sympatico.ca> writes:
Rudolf wrote:
In article <dC*********************@news20.bellglobal.com>,
Lew Pitcher <Le*********@td.com> wrote:

4) what makes you believe that a char is not more than 4 bytes long?

I thought that the standard defines/requires that sizeof(char) is one?


Smarta** :-)

Read my question in context. The OP is counting machine bytes (octets), not C
bytes, and I answered in the same context.


The OP didn't use the word "octet". If someone uses the word "byte"
in this newsgroup, he might *mean* "octet", but we should assume he's
talking about C bytes.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #15

P: n/a
On 19 Jan 2005 07:27:07 -0800, "puzzlecracker" <ir*********@gmail.com>
wrote in comp.lang.c:

2)
struct B
{
int i;
short int si;
char c;
char d;
int j;
};


32 bit machine
--------------
1st block: i+pad = 4 bytes
2rd block: s1+pad = 4 bytes
3rd block" c+pad = 4 bytes
4th block: d+ pad = 4 bytes
5th block: j+pad = 4 bytes
---------------------------------------
TOTAL: 20 bytes


No, not my 32-bit machine (AD SHARC):

int i: 1 byte
short int si: 1 byte
char c: 1 byte
char d: 1 byte
int j: 1 byte

Total: 20 bytes.

Padding: 0 bytes.

Will you get it through your THICK HEAD that none of this is a
language issue? The C language specifies nothing at all about this,
merely states that some implementations might have alignment
requirements. If they do it is up to them what they are, and you are
up the creek if you violate them.

If you want to talk about a particular 32-bit compiler, find that
compiler's newsgroup.
would explain how to use sizeof to determine that as well?
what is POD and ALIGNED ADDRESS?


There is no such thing as POD in C, it is a C++ term.

--
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/~a...FAQ-acllc.html
Nov 14 '05 #16

P: n/a
On 19 Jan 2005 10:09:10 -0800, "puzzlecracker" <ir*********@gmail.com>
wrote in comp.lang.c:
Unbelievable! Ok I know it is platform dependent; stop reminding it
to me. What I am looking for is rules applied that should be
independent of platform in question. Let's agree on a standard,
elaborate on the rules relevent to it.


*plonk*

--
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/~a...FAQ-acllc.html
Nov 14 '05 #17

P: n/a
On Wed, 19 Jan 2005 17:14:24 -0700, in comp.lang.c , Rudolf
<rt*****@bigfoot.com> wrote:
In article <dC*********************@news20.bellglobal.com>,
Lew Pitcher <Le*********@td.com> wrote:
4) what makes you believe that a char is not more than 4 bytes long?


I thought that the standard defines/requires that sizeof(char) is one?


Provided you define a byte as a char (which is the C definition), your
point is valid. However if you define a byte as 8 bits, a common if
erroneous definition, your point is less valid...
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Nov 14 '05 #18

This discussion thread is closed

Replies have been disabled for this discussion.