On Tue Oct 04, 2005 at 10:15:49 +1000, O Plameras wrote:
>Benno wrote:
>
>>On Sat Oct 01, 2005 at 18:23:40 +1000, O Plameras wrote:
>>
<snippety>
>
>What do you mean ? Can you illustrate with C codes ? Do you mean that a
>struct
>are not allocated contiguous memory ? Do you mean a struct components are
>allocated random memory. If it does not allocate contiguous memory in your
>thinking, what about arrays since struct is similar to arrays except the
>objects are
>of mixed types ?
>
>And when struct components are allocated random memory, this breaks down
>the
>nature and the power of C which to my mind lie in its ability to
>manipulate and
>manage objects using pointers and pointer-arithmetic.
What I mean is how the structure is layed out in memory is not defined by
the specification, and is up to the C compiler, or rather give the
implementation
plenty of flexibility in the layout.
so
struct foo {
char x;
char y;
int z;
};
Could be layed out in memory as: (numbers in brackets refer to clause in C99
spec)
[ x | y | z ]
or possibly
[ x padding | y padding | z ] (6.7.2.1.12)
or more likely
[ x | y | padding | z ]
although it can't be
[ y | x | z ] (6.7.2.1.13)
and it also can't be:
[ padding x | y | z] (6.7.2.1.13)
"""
#include <stdio.h>
#include <stddef.h>
struct foo {
char x;
int y;
};
int main(void)
{
struct foo foo;
printf("Offset of: x: %zd y: %zd\n",
offsetof(struct foo, x),
offsetof(struct foo, y));
if (sizeof(foo.x) == offsetof(struct foo, y))
printf("sizeof(foo.x) == offsetof(struct foo, y)\n");
else
printf("sizeof(foo.x) != offsetof(struct foo, y)\n");
}
"""
Demonstrates this. For example compiling normally with gcc will output:
Offset of: x: 0 y: 4
sizeof(foo.x) != offsetof(struct foo, y)
compiling with -fpack-struct results in:
Offset of: x: 0 y: 1
sizeof(foo.x) == offsetof(struct foo, y)
As far as I know:
struct foo;
struct foo a[];
&(a[1]) == ((uintptr_t) &a[0]) + sizeof(struct foo); (6.5.6.9 footnote 88)
>>Matthew said is wasn't `necessarily' bound to the hardware. In practise you
>>are going to see different data type sizes on different bits of hardware.
>>But just because the hardware can store an 64-bit words, doesn't mean that
>>the ABI is going to specify an int to be 64-bit.
>>
>>
>What you probably mean is it is not mandated by the standard. Some specs
>are mandated
>and some are not.
Thats exactly what I mean. The C99 specification does not mandate the size
of types. The platform (that is OS + architecture) usually defines an ABI
which compilers should use. It does (usually) specifiy the size of the types.
>That's why I used specific C codes to illustrate. Whether the C codes
>that I used follows
>the standard in the sense that it does not violate the standard it is
>compliant. After all
>compliance means it does not violate mandated standards.
>
>And in intel or amd 16-bit and 32-bit it is as demonstrated. That's what
>I meant.
What you provided is compliant C, however making any assumption on the
underlying
bus speed, hardware word size, based on the size of an integer is just not going
to work, which appears to be what you are trying to say. There
is no specified relationship between hardware word size and sizeof(int). In some
ABI hwardware word size == sizeof(int), (ia32, some 16bit processors, VAX maybe)
and in others hardward word size != sizeof(int) (amd64, itanium, power4).
Benno
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
