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]

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]

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]

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.

 

[Roberto Waltman]

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]

why not?

Tom

What a useless answer.

Why not just tell him there is padding?

 

[jaysome]

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]

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.

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]

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

[/QUOTE]

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]

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));
}

[/QUOTE]

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]

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]

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?

 

[Dann Corbit]

[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/globalization/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]

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]

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.

 

[Flash Gordon]

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.

 

[Stephen Sprunk]

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