sizeof()

[Jack]

For the structure below:

struct A{
int a;
double b;
char c;
};

struct A sa;
printf("sizeof(A): %d\n", sizeof(sa));

The output is
sizeof(A): 16

Why it is 16?

Thanks.

Jack

[Tom St Denis]

Jack wrote:

For the structure below:

struct A{
int a;
double b;
char c;
};

struct A sa;
printf("sizeof(A): %d\n", sizeof(sa));

The output is
sizeof(A): 16

Why it is 16?

why not?

Tom

[Robert Gamble]

Jack wrote:

For the structure below:

struct A{
int a;
double b;
char c;
};

struct A sa;
printf("sizeof(A): %d\n", sizeof(sa));

The output is
sizeof(A): 16

Why it is 16?

Read the FAQ, <http://c-faq.com/>, question 2.13.

Robert Gamble

[Walter Roberson]

In article <11*********************@i3g2000cwc.googlegroups.c om>,
Jack <ju******@gmail.comwrote:

>For the structure below:

>struct A{
int a;
double b;
char c;
};

struct A sa;
printf("sizeof(A): %d\n", sizeof(sa));

>The output is
sizeof(A): 16

>Why it is 16?

That implementation probably uses 4 bytes for int, 8 bytes for double,
1 byte for char. But implementations are required to pad structures so
that the size of the structure is a multiple of the architectural
alignment restrictions (often 4 bytes), so the structure likely gets
padded by adding 3 unused bytes.

If the structure were not padded, then if you had

struct A sa2[2];

then the address of sa2[1] would be 13 bytes after the start of sa2[0]
and you would be asking the system to read an int from an odd byte
address. A lot of systems cannot do that, or can only do that by using
special trap handlers, or can only do it by using special
"load unaligned" instructions that are often very slow.
--
"law -- it's a commodity"
-- Andrew Ryan (The Globe and Mail, 2005/11/26)

[Roberto Waltman]

"Jack" <ju******@gmail.comwrote:

>For the structure below:

struct A{
int a;
double b;
char c;
};

struct A sa;
printf("sizeof(A): %d\n", sizeof(sa));

The output is
sizeof(A): 16

Why it is 16?

Probably because sizeof(int) is 4, sizeof(double) is 8, sizeof(char)
is 1 (of course,) and 3 chars of padding are added to guarantee proper
alignment.

But it could also be that in your machine sizeof(int) is 1,
sizeof(double) is 14 and no padding is necessary.

Or maybe sizeof(int) is 7, followed by one char padding,
sizeof(double) is 5, followed by one char padding, plus the size of c
and one last char of padding for alignment.

Or any other valid combination adding up to 16.

Check your compiler's documentation for the sizes of the primitive
data types and alignment requirements.

Roberto Waltman

[ Please reply to the group,
return address is invalid ]

[dbtid]

Tom St Denis wrote:

Jack wrote:

>For the structure below:

struct A{
int a;
double b;
char c;
};

struct A sa;
printf("sizeof(A): %d\n", sizeof(sa));

The output is
sizeof(A): 16

Why it is 16?

why not?

Tom

What a useless answer.

Why not just tell him there is padding?

[jaysome]

On 19 Jul 2006 08:58:01 -0700, "Robert Gamble" <rg*******@gmail.com>
wrote:

>Jack wrote:

>For the structure below:

struct A{
int a;
double b;
char c;
};

struct A sa;
printf("sizeof(A): %d\n", sizeof(sa));

The output is
sizeof(A): 16

Why it is 16?

Read the FAQ, <http://c-faq.com/>, question 2.13.

which says:

Q. Why does sizeof report a larger size than I expect for a structure
type, as if there were padding at the end?

A. Padding at the end of a structure may be necessary to preserve
alignment when an array of contiguous structures is allocated. Even
when the structure is not part of an array, the padding remains, so
that sizeof can always return a consistent size. See also question
2.12.

References: H&S Sec. 5.6.7 pp. 139-40

Best regards
--
jay

NOTE: The C FAQ book has the same contents as the online C FAQ and
more. The online version is great and the book is even better. Find
out more here:

http://c-faq.com/book/

[sarathy]

Walter Roberson wrote:

In article <11*********************@i3g2000cwc.googlegroups.c om>,
Jack <ju******@gmail.comwrote:

For the structure below:

struct A{
int a;
double b;
char c;
};

struct A sa;
printf("sizeof(A): %d\n", sizeof(sa));

The output is
sizeof(A): 16

Why it is 16?

That implementation probably uses 4 bytes for int, 8 bytes for double,
1 byte for char. But implementations are required to pad structures so
that the size of the structure is a multiple of the architectural
alignment restrictions (often 4 bytes), so the structure likely gets
padded by adding 3 unused bytes.

If the structure were not padded, then if you had

struct A sa2[2];

then the address of sa2[1] would be 13 bytes after the start of sa2[0]
and you would be asking the system to read an int from an odd byte
address. A lot of systems cannot do that, or can only do that by using
special trap handlers, or can only do it by using special
"load unaligned" instructions that are often very slow.
--
"law -- it's a commodity"
-- Andrew Ryan (The Globe and Mail, 2005/11/26)

What does it mean that system cannot read odd byte address ?
Is this due to the concept of word length, which is the basic length of
a memory address.
If such is the case, then how is memory allocated for following case.

Consider that word length is 4. For the struct,

struct a
{
char c;
};
int main()
{
struct a b[10];
printf ("size = %d\n",sizeof(b));
}

As per the discussion, should the answer be 40 (3 bytes padded for
evrey 1 char)????
so that there is not need for reading odd byte address?
Correct me if this not true.

Sarathy

[Richard Tobin]

In article <11**********************@s13g2000cwa.googlegroups .com>,
sarathy <sp*********@gmail.comwrote:

>and you would be asking the system to read an int from an odd byte
address. A lot of systems cannot do that

>What does it mean that system cannot read odd byte address ?

He said read *an int* from an odd byte address. Many modern machines
can read a single byte from any location, but a 2-byte word only from
even addresses, a 4-byte word only from multiple-of-4 addresses, and
so on.

>Consider that word length is 4. For the struct,

struct a
{
char c;
};
int main()
{
struct a b[10];
printf ("size = %d\n",sizeof(b));
}

As per the discussion, should the answer be 40 (3 bytes padded for
evrey 1 char)????

In this case, you never need to read anything bigger than char, so alignment
isn't likely to be a problem. sizeof(b) will probably be 10.

-- Richard

[Giorgio Silvestri]

"Richard Tobin" <ri*****@cogsci.ed.ac.ukha scritto nel messaggio
news:e9***********@pc-news.cogsci.ed.ac.uk...

In article <11**********************@s13g2000cwa.googlegroups .com>,
sarathy <sp*********@gmail.comwrote:

and you would be asking the system to read an int from an odd byte
address. A lot of systems cannot do that

What does it mean that system cannot read odd byte address ?

He said read *an int* from an odd byte address. Many modern machines
can read a single byte from any location, but a 2-byte word only from
even addresses, a 4-byte word only from multiple-of-4 addresses, and
so on.

Consider that word length is 4. For the struct,

struct a
{
char c;
};
int main()
{
struct a b[10];
printf ("size = %d\n",sizeof(b));
}

No.

sizeof(b) is of type 'size_t'.
It can be bigger than 'int'.
#include <stdio.h>
#include <stdlib.h>

struct a
{
char c;
};

int main(void)
{
struct a b[10];

/* I suppose sizeof(b) <= INT_MAX :-) */
printf ("size = %d\n",(int)sizeof(b));

return EXIT_SUCCESS;
}

In C99 you can use also %zu.

Giorgio Silvestri

[Barry Schwarz]

On Thu, 20 Jul 2006 03:33:18 GMT, dbtid <db****@nospam.gmail.com>
wrote:

>Tom St Denis wrote:

>Jack wrote:

>>For the structure below:

struct A{
int a;
double b;
char c;
};

struct A sa;
printf("sizeof(A): %d\n", sizeof(sa));

The output is
sizeof(A): 16

Why it is 16?

why not?

Tom

What a useless answer.

Why not just tell him there is padding?

Because sizeof(int) could be 7, sizeof(double) could be 8, and
sizeof(char) must be 1. No padding at all.
Remove del for email

[Ronald Bruck]

In article <uh********************************@4ax.com>, Barry Schwarz
<sc******@doezl.netwrote:

On Thu, 20 Jul 2006 03:33:18 GMT, dbtid <db****@nospam.gmail.com>
wrote:

Tom St Denis wrote:

Jack wrote:
For the structure below:

struct A{
int a;
double b;
char c;
};

struct A sa;
printf("sizeof(A): %d\n", sizeof(sa));

The output is
sizeof(A): 16

Why it is 16?

why not?

Tom

What a useless answer.

Why not just tell him there is padding?

Because sizeof(int) could be 7, sizeof(double) could be 8, and
sizeof(char) must be 1. No padding at all.

This brings up a problem I've wondered about: what support is there in
C for two-byte characters? I can foresee, in not too many years, the
ordinary char going the way of the "short"--provided for efficiency,
but not often used. That way, I'll be able to get even MORE junk
e-mail in Kanji :-(

Googling and Wikipedia-ing, I find info on XDR (eXternal Data
Representation), but nothing specifically about C, except a library
provided by IBM. Is this done externally to C? Is there some standard
library for it?

--
Ron Bruck

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com

[Dann Corbit]

"Ronald Bruck" <br***@math.usc.eduwrote in message
news:20**********************@math.usc.edu...
[snip]

This brings up a problem I've wondered about: what support is there in
C for two-byte characters? I can foresee, in not too many years, the
ordinary char going the way of the "short"--provided for efficiency,
but not often used. That way, I'll be able to get even MORE junk
e-mail in Kanji :-(

Googling and Wikipedia-ing, I find info on XDR (eXternal Data
Representation), but nothing specifically about C, except a library
provided by IBM. Is this done externally to C? Is there some standard
library for it?

You are referring to ICU, I imagine.
http://www-306.ibm.com/software/glob.../icu/index.jsp

That is the only tool set that I know of that is full featured enough to
solve the typical problem set associated with internationalization.

If you need to do internationalization of your software projects, then I can
say that I highly recommend it. We use it with C++ but I gather that it can
also be used from C.

[Peter Shaggy Haywood]

Groovy hepcat Jack was jivin' on 19 Jul 2006 08:51:05 -0700 in
comp.lang.c.
sizeof()'s a cool scene! Dig it!

>For the structure below:

struct A{
int a;
double b;
char c;
};

struct A sa;
printf("sizeof(A): %d\n", sizeof(sa));

The output is
sizeof(A): 16

Why it is 16?

Who can tell? Since you are invoking undefined behaviour, anything
could happen. You could get 99.99999 as output, though that's highly
unlikely. You could get pink snow falling in your bedroom, though
that's even less likely. Much more likely is a bogus integer output
such as 0, or a crash, or the number of bytes in the structure (which
may be 16) being output. You can never be sure with undefined
behaviour.
Remember, sizeof returns a value of type size_t, an implementation
defined unsigned integer type. It might be unsigned int, unsigned long
or even unsigned char or some other type. C99 defines a printf()
conversion specifier for size_t. If you have a C99 implementation and
don't care about backward compatibility with C90, you can use that.
Otherwise, you should cast the result of sizeof to a known type
(preferebly unsigned long) and use the coresponding conversion
specifier.

printf("sizeof sa: %lu\n", (unsigned long)sizeof sa);

Then your output will be meaningful.

--

Dig the even newer still, yet more improved, sig!

http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?

[Matt Junx]

Giorgio Silvestri wrote:

>
"Richard Tobin" <ri*****@cogsci.ed.ac.ukha scritto nel messaggio
news:e9***********@pc-news.cogsci.ed.ac.uk...

>In article <11**********************@s13g2000cwa.googlegroups .com>,
sarathy <sp*********@gmail.comwrote:

>and you would be asking the system to read an int from an odd byte
address. A lot of systems cannot do that

>What does it mean that system cannot read odd byte address ?

He said read *an int* from an odd byte address. Many modern machines
can read a single byte from any location, but a 2-byte word only from
even addresses, a 4-byte word only from multiple-of-4 addresses, and
so on.

>Consider that word length is 4. For the struct,

struct a
{
char c;
};
int main()
{
struct a b[10];
printf ("size = %d\n",sizeof(b));
}

No.

sizeof(b) is of type 'size_t'.
It can be bigger than 'int'.
#include <stdio.h>
#include <stdlib.h>

struct a
{
char c;
};

int main(void)
{
struct a b[10];

/* I suppose sizeof(b) <= INT_MAX :-) */
printf ("size = %d\n",(int)sizeof(b));

return EXIT_SUCCESS;
}

In C99 you can use also %zu.

Giorgio Silvestri

I haven't read the standard (and can't afford to fork over the money to get
a copy from ISO), but wouldn't it make sense if size_t was always defined
as an unsigned int? int tends to be the architecture size, so unsigned int
would cover anything the size of the total available memory. Then again,
that also makes more sense for things like offset_t and related, so maybe
I'm just rambling.

[Walter Roberson]

In article <Of******************************@comcast.com>,
Matt Junx <bo****@gmail.comwrote:

>I haven't read the standard (and can't afford to fork over the money to get
a copy from ISO), but wouldn't it make sense if size_t was always defined
as an unsigned int? int tends to be the architecture size, so unsigned int
would cover anything the size of the total available memory.

No. unsigned long would be a more likely candidate.

For example, in SGI IRIX, programs compiled in 64 bit mode have:
char - 1 byte
short - 2 bytes
int - 4 bytes
long - 8 bytes
int is usually a natural -arithmetic- type; long is more likely to
correspond to the maximum natural architecture size.
--
All is vanity. -- Ecclesiastes

[Flash Gordon]

Walter Roberson wrote:

In article <Of******************************@comcast.com>,
Matt Junx <bo****@gmail.comwrote:

>I haven't read the standard (and can't afford to fork over the money to get
a copy from ISO), but wouldn't it make sense if size_t was always defined
as an unsigned int? int tends to be the architecture size, so unsigned int
would cover anything the size of the total available memory.

<snip>

int is usually a natural -arithmetic- type; long is more likely to
correspond to the maximum natural architecture size.

In addition, I suggest the OP look at
http://clc-wiki.net/wiki/C_standardisation:ISO which says where you can
*legally* get a free copy of the last public C89 draft and the current
public draft which is C99 + TCs.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[Stephen Sprunk]

"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.cawrote in message
news:ea**********@canopus.cc.umanitoba.ca...

In article <Of******************************@comcast.com>,
Matt Junx <bo****@gmail.comwrote:

>>I haven't read the standard (and can't afford to fork over the money to
get
a copy from ISO), but wouldn't it make sense if size_t was always defined
as an unsigned int? int tends to be the architecture size, so unsigned
int
would cover anything the size of the total available memory.

No. unsigned long would be a more likely candidate.

For example, in SGI IRIX, programs compiled in 64 bit mode have:
char - 1 byte
short - 2 bytes
int - 4 bytes
long - 8 bytes

int is usually a natural -arithmetic- type; long is more likely to
correspond to the maximum natural architecture size.

That works on LP64 systems, but not IL32LLP64 ones (like some x64
implementations).

size_t is likely to be unsigned long long if the system has that, and
unsigned long if it doesn't. Hopefully there are aren't too many systems
out there that have 64-bit pointers and no long long support :)

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

--
Posted via a free Usenet account from http://www.teranews.com