about structures memory allocation

[Barry Schwarz]

# how much memory is allocated for following structure

None. Structures only exist in the compiler; in the code
you have blocks of allocated memory and offsets into them.

A variable of type T needs no more than sizeof(T) char sized
units allocated on appropriate memory boundary.

# struct bharath
# {
# int b;
# char c;
# float d;
# }

A variable of type (struct bharath) will be allocated at
least sizeof(struct bharath) bytes. How a compiler allocates

Would you care to give an example of when it will be allocated more
than sizeof(srtuct bharath) bytes?

the space is really up to the compiler. If you need to know
there are field offset macros to find otu where each field
begins in the variable's allocated space.

Remove del for email

 

[Gordon Burditt]

# how much memory is allocated for following structure

Would you care to give an example of when it will be allocated more
than sizeof(srtuct bharath) bytes?

If struct bharath requires padding so the second element of an array
of struct bharath is properly aligned, the padding is part of
sizeof(struct bharath). In other words, the padding goes *INSIDE*
the struct, not between array elements in an array of this struct.

There might be padding between auto variables if, for example, a
long long requires stricter alignment than a struct bharath and
happens to come after one and would end up misaligned. Which
variable you "blame" or "charge" for the padding is better determined
by a course in cost accounting rather than C.

malloc(sizeof(struct bharath)) may allocate more memory than
requested, among other reasons, so it can satisfy the requirement
that allocations are aligned suitably for any object. For example,
int and float may be aligned on a 4-byte boundary (so sizeof(struct
bharath) might come out 12, including 3 bytes of padding after the
char), but malloc() may round a request up to a multiple of 8,
because there might be other things (say, long long and double)
which are aligned to a multiple of 8. This also doesn't account
for the possibility that malloc() may also allocate space for
internal bookkeeping information used to keep track of allocated
and free blocks.

 

[Keith Thompson]

On Sun, 24 Jun 2007 00:10:45 -0000, SM Ryan


Would you care to give an example of when it will be allocated more
than sizeof(srtuct bharath) bytes?

malloc(sizeof(struct bharath)) can easily allocate more than
sizeof(struct bharath) bytes. Even for an object declaration, there
may be a gap between the object and the next object in memory.

You could argue, of course, that the extra bytes aren't allocated *to
the object*, but are just padding outside the object (and I wouldn't
disagree).

 

[Barry Schwarz]

If struct bharath requires padding so the second element of an array
of struct bharath is properly aligned, the padding is part of
sizeof(struct bharath). In other words, the padding goes *INSIDE*
the struct, not between array elements in an array of this struct.

That was my obviously too subtle point to the OP.

There might be padding between auto variables if, for example, a
long long requires stricter alignment than a struct bharath and
happens to come after one and would end up misaligned. Which
variable you "blame" or "charge" for the padding is better determined
by a course in cost accounting rather than C.

This has nothing to do with the question asked.

malloc(sizeof(struct bharath)) may allocate more memory than
requested, among other reasons, so it can satisfy the requirement
that allocations are aligned suitably for any object. For example,
int and float may be aligned on a 4-byte boundary (so sizeof(struct
bharath) might come out 12, including 3 bytes of padding after the
char), but malloc() may round a request up to a multiple of 8,
because there might be other things (say, long long and double)
which are aligned to a multiple of 8. This also doesn't account
for the possibility that malloc() may also allocate space for
internal bookkeeping information used to keep track of allocated
and free blocks.

All true but unrelated to the question. The OP is talking about
defined objects, not about dynamic allocation.

And it would really help if you did not delete attributions.


Remove del for email

 

[Barry Schwarz]

malloc(sizeof(struct bharath)) can easily allocate more than
sizeof(struct bharath) bytes. Even for an object declaration, there
may be a gap between the object and the next object in memory.

malloc does not allocate objects. It allocates the requested amount
of space suitably aligned for any object.

Why is everyone stripping out the next section of the original post
where he made it clear he was talking about how the compiler allocates
space for defined objects?

You could argue, of course, that the extra bytes aren't allocated *to
the object*, but are just padding outside the object (and I wouldn't
disagree).

Remove del for email

 

[Keith Thompson]

malloc does not allocate objects. It allocates the requested amount
of space suitably aligned for any object.

That's arguable. An object is a "region of data storage in the
execution environment, the contents of which can represent values".
That's pretty much what malloc allocates.

Why is everyone stripping out the next section of the original post
where he made it clear he was talking about how the compiler allocates
space for defined objects?

Um, what section was that? Here's the original post in its entirety:

| how much memory is allocated for following structure
| struct bharath
| {
| int b;
| char c;
| float d;
| }
|
| and how?

Just a type declaration.

Now I'm really just nitpicking here, not arguing any significant
point. It's true that anything that allocates an object of type
struct bharath, either an object declaration or a malloc call, can
easily allocate more that sizeof(struct bharath) bytes. It's also
true that the size of any struct bharath object is, by definition,
sizeof(struct bharath) bytes.

 

[jaysome]

(e-mail address removed) wrote:
[snip]

what i want actually is how much size will be allocated for above
structuer in a 16 bit machine

Enough to hold the structure, plus any padding, on this specific 16-bit
machine.

No, actually, just enough to hold the structure. If there is any
padding in the structure, it is _IN_ the structure.

#include <stdio.h>
#include <stddef.h>

struct foo
{
double d;
char c;
};

int main(void)
{
struct foo f;
printf("offsetof(d) = %d\n", (int)offsetof(struct foo,d));
printf("offsetof(c) = %d\n", (int)offsetof(struct foo,c));
printf("sizeof(d) = %d\n", (int)sizeof(f.d));
printf("sizeof(c) = %d\n", (int)sizeof(f.c));
printf("sizeof(struct foo) = %d\n", (int)sizeof(struct foo));
return 0;
}

Output:

offsetof(d) = 0
offsetof(c) = 8
sizeof(d) = 8
sizeof(c) = 1
sizeof(struct foo) = 16

There appears to padding in this structure, but is it really _IN_ the
structure?

 

[J. J. Farrell]

On Thu, 21 Jun 2007 11:29:36 -0400, Clever Monkey

(e-mail address removed) wrote:

[snip]

what i want actually is how much size will be allocated for above
structuer in a 16 bit machine
Enough to hold the structure, plus any padding, on this specific 16-bit
machine.

No, actually, just enough to hold the structure. If there is any
padding in the structure, it is _IN_ the structure.

#include <stdio.h>
#include <stddef.h>

struct foo
{
double d;
char c;

};

int main(void)
{
struct foo f;
printf("offsetof(d) = %d\n", (int)offsetof(struct foo,d));
printf("offsetof(c) = %d\n", (int)offsetof(struct foo,c));
printf("sizeof(d) = %d\n", (int)sizeof(f.d));
printf("sizeof(c) = %d\n", (int)sizeof(f.c));
printf("sizeof(struct foo) = %d\n", (int)sizeof(struct foo));
return 0;

}

Output:

offsetof(d) = 0
offsetof(c) = 8
sizeof(d) = 8
sizeof(c) = 1
sizeof(struct foo) = 16

There appears to padding in this structure, but is it really _IN_ the
structure?

Yes; that's what your example shows.

 

[Army1987]

]
struct bharath
{
int b;
char c;
float d;
}

A variable of type (struct bharath) will be allocated at
least sizeof(struct bharath) bytes. How a compiler allocates

Would you care to give an example of when it will be allocated more
than sizeof(srtuct bharath) bytes?

malloc(sizeof(struct bharath)) can easily allocate more than
sizeof(struct bharath) bytes. Even for an object declaration, there
may be a gap between the object and the next object in memory.

malloc does not allocate objects. It allocates the requested amount
of space suitably aligned for any object.

That's arguable. An object is a "region of data storage in the
execution environment, the contents of which can represent values".
That's pretty much what malloc allocates.

Why is everyone stripping out the next section of the original post
where he made it clear he was talking about how the compiler allocates
space for defined objects?

Um, what section was that? Here's the original post in its entirety:

| how much memory is allocated for following structure
| struct bharath
| {
| int b;
| char c;
| float d;
| }
|
| and how?

Just a type declaration.

Now I'm really just nitpicking here, not arguing any significant
point. It's true that anything that allocates an object of type
struct bharath, either an object declaration or a malloc call, can
easily allocate more that sizeof(struct bharath) bytes. It's also
true that the size of any struct bharath object is, by definition,
sizeof(struct bharath) bytes.

In something like
int main(void)
{
struct bharath b;
long long ll;
...
}
since the standard requires nothing about the placement of auto
variables, it is well possible that there is some space between
b and ll, but an auto char in an inner block might well be put into
that space. (Yes, I don't think it is very likely to happen...)
So, as far as a reasonable definition of "to allocate" is
concerned, these two declarations allocate exactly sizeof b +
sizeof ll bytes, even if they are not contiguous.

 

[Barry Schwarz]

]
struct bharath
{
int b;
char c;
float d;
}

A variable of type (struct bharath) will be allocated at
least sizeof(struct bharath) bytes. How a compiler allocates

Would you care to give an example of when it will be allocated more
than sizeof(srtuct bharath) bytes?

malloc(sizeof(struct bharath)) can easily allocate more than
sizeof(struct bharath) bytes. Even for an object declaration, there
may be a gap between the object and the next object in memory.

malloc does not allocate objects. It allocates the requested amount
of space suitably aligned for any object.

That's arguable. An object is a "region of data storage in the
execution environment, the contents of which can represent values".
That's pretty much what malloc allocates.

Why is everyone stripping out the next section of the original post
where he made it clear he was talking about how the compiler allocates
space for defined objects?

Um, what section was that? Here's the original post in its entirety:

| how much memory is allocated for following structure
| struct bharath
| {
| int b;
| char c;
| float d;
| }
|
| and how?

Not entirely. Here is the section I originally responded to and in
which I imbedded my original question regarding the OP's assertion of
**at least** so many bytes:

"A variable of type (struct bharath) will be allocated at
least sizeof(struct bharath) bytes. How a compiler allocates
the space is really up to the compiler. If you need to know
there are field offset macros to find otu where each field
begins in the variable's allocated space."

Note that it talks about the compiler and not the run time library.


Remove del for email

 

[CBFalconer]

.... snip ...

In something like
int main(void) {
struct bharath b;
long long ll;
...
}
since the standard requires nothing about the placement of auto
variables, it is well possible that there is some space between
b and ll, but an auto char in an inner block might well be put into
that space. (Yes, I don't think it is very likely to happen...)
So, as far as a reasonable definition of "to allocate" is
concerned, these two declarations allocate exactly sizeof b +
sizeof ll bytes, even if they are not contiguous.

A long long requires <sizeof long long\> bytes, not 11.

 

[Joe Wright]

malloc(sizeof(struct bharath)) can easily allocate more than
sizeof(struct bharath) bytes. Even for an object declaration, there
may be a gap between the object and the next object in memory.

I don't think so. First, sizeof (struct bharath) is 12 at my house. The
offsetof the members are 0, 4 and 8 regardless of their arrangement. If
the char member is the last it is still at offset 8 and sizeof the
struct is still 12. There can be no gap between the object and the next
object.

You could argue, of course, that the extra bytes aren't allocated *to
the object*, but are just padding outside the object (and I wouldn't
disagree).

There are no 'extra bytes' that you can find. That malloc might allocate
more than asked for is true but not at issue.

struct bharath *bhar = malloc(3 * sizeof *bhar);

If successful, this will allocate at least 36 bytes for three instances
of the struct. malloc may allocate more for its own purposes but we
can't know and don't care.

Or did I misunderstand you?

 

[Harald van =?UTF-8?B?RMSzaw==?=]

A long long requires <sizeof long long\> bytes, not 11.

A variable named LL requires sizeof LL bytes, and the lowercase equivalent
requires sizeof ll bytes.

 

[Keith Thompson]

A long long requires <sizeof long long\> bytes, not 11.

Chuck, if you can't tell the difference between "l" (lowercase L) and
"1" (digit one), get a better font. At least take a closer look
before assuming that somebody wrote something nonsensical like "sizeof
11". (Yes, "sizeof 11" is legal, but it makes no sense in context.)

 

[Keith Thompson]

I don't think so. First, sizeof (struct bharath) is 12 at my
house. The offsetof the members are 0, 4 and 8 regardless of their
arrangement. If the char member is the last it is still at offset 8
and sizeof the struct is still 12. There can be no gap between the
object and the next object.

Sure there can.

Suppose sizeof(struct bharath) is 12, and suppose you have another
type struct foo that requires 16-byte alignment. Then if you declare

struct bharath obj1;
struct foo obj2;

there easily *could* be a 4-byte gap between obj1 and obj2. Or the
compiler could reverse the order, or it could allocate another object
between obj1 and obj2, or whatever.

I'm not saying this is of any particular importance, just that it's
possible and plausible.

I'm sure you know this, and I suspect I'm misinterpreting your
statement that "There can be no gap between the object and the next
object."; can you clarify what you mean?

There are no 'extra bytes' that you can find. That malloc might
allocate more than asked for is true but not at issue.

Ok, so what exactly is the issue? I think I've lost track.

I think we all know what the answers are, and we're arguing over what
the question is, or perhaps what the question should be.

[...]

 

[Joe Wright]

]
struct bharath
{
int b;
char c;
float d;
}
A variable of type (struct bharath) will be allocated at
least sizeof(struct bharath) bytes. How a compiler allocates
Would you care to give an example of when it will be allocated more
than sizeof(srtuct bharath) bytes?
malloc(sizeof(struct bharath)) can easily allocate more than
sizeof(struct bharath) bytes. Even for an object declaration, there
may be a gap between the object and the next object in memory.

I don't think so. First, sizeof (struct bharath) is 12 at my
house. The offsetof the members are 0, 4 and 8 regardless of their
arrangement. If the char member is the last it is still at offset 8
and sizeof the struct is still 12. There can be no gap between the
object and the next object.

Sure there can.

Suppose sizeof(struct bharath) is 12, and suppose you have another
type struct foo that requires 16-byte alignment. Then if you declare

struct bharath obj1;
struct foo obj2;

there easily *could* be a 4-byte gap between obj1 and obj2. Or the
compiler could reverse the order, or it could allocate another object
between obj1 and obj2, or whatever.

I wasn't thinking about a gap between obj1 and obj2. If there is such a
gap we don't care and I think we can't even test for it.

I'm not saying this is of any particular importance, just that it's
possible and plausible.

I'm sure you know this, and I suspect I'm misinterpreting your
statement that "There can be no gap between the object and the next
object."; can you clarify what you mean?

I was alluding to an array of the particular structure.

Ok, so what exactly is the issue? I think I've lost track.

I think we all know what the answers are, and we're arguing over what
the question is, or perhaps what the question should be.

Indeed. I got sideways on the 'extra bytes' thing.

 

[SM Ryan]

# >>> Would you care to give an example of when it will be allocated more
# >>> than sizeof(srtuct bharath) bytes?
# >> malloc(sizeof(struct bharath)) can easily allocate more than
# >> sizeof(struct bharath) bytes. Even for an object declaration, there
# >> may be a gap between the object and the next object in memory.

Sometimes a compiler will allocate variables in word sized units
to improve performance. As far as such compilers are concerned,
the variable is a whole number of words which can be greater
than the sizeof.

 

[Frodo Baggins]

(e-mail address removed) said:


None. It's a type, not an object.

A newbie question: surely, the struct definition is stored somewhere.
Else, how would the struct be allocated at runtime? And this would
require some memory...

Regards,
Frodo B

 

[Barry Schwarz]

# >>> Would you care to give an example of when it will be allocated more
# >>> than sizeof(srtuct bharath) bytes?
# >> malloc(sizeof(struct bharath)) can easily allocate more than
# >> sizeof(struct bharath) bytes. Even for an object declaration, there
# >> may be a gap between the object and the next object in memory.

Sometimes a compiler will allocate variables in word sized units
to improve performance. As far as such compilers are concerned,
the variable is a whole number of words which can be greater
than the sizeof.

No it cannot. The reason is that elements of an array must abut and
the byte difference between the start of one element and the next
element must be exactly sizeof element. If the compiler elects to pad
a structure out to a word boundary, then that padding is included the
value that sizeof evaluates to.


Remove del for email

 

[Richard Heathfield]

Frodo Baggins said:

A newbie question: surely, the struct definition is stored somewhere.

Yes, the compiler will need to store the definition in its own internal
memory, but in those terms the question is unanswerable without
detailed internal knowledge of the compiler working. But that's not
normally what we mean when we say "how much memory".

Else, how would the struct be allocated at runtime?

It wouldn't be. It's a type, not an object. You don't allocate types.