what's the size of type char foo[3] ?

I am wondering if (on a conforming hosted implementation of C99)
the following program is guaranteed to output: 3 3

Specifically, I'm afraid that there could be some padding,
either for type foo, or variable bar.

#include <stdio.h>
typedef char foo[3];
int main(void) {
foo bar;
printf("%u %u\n",(unsigned)sizeof(foo),(unsigned)sizeof bar);
return 0;
}

Francois Grieu <fgrieu@gmail.com> writes:
>I am wondering if (on a conforming hosted implementation of C99)
>the following program is guaranteed to output: 3 3

z Specifies that a following d, i, o, u, x, or X
conversion specifier applies to a size_t

, so

printf( "%zu\n", sizeof( alpha ));

(untested).

Francois Grieu <fgrieu@gmail.com> writes:

> I am wondering if (on a conforming hosted implementation of C99)
> the following program is guaranteed to output: 3 3
>
> Specifically, I'm afraid that there could be some padding,
> either for type foo, or variable bar.
>
> #include <stdio.h>
> typedef char foo[3];
> int main(void) {
> foo bar;
> printf("%u %u\n",(unsigned)sizeof(foo),(unsigned)sizeof bar);
> return 0;
> }

I was going to say "yes" -- sizeof(char) is 1 and arrays can't have any
padding between the elements -- but then I found I could not, at first
reading, rule out arrays having padding after the last element. It
would be daft, of course, but I can't see why it is not permitted.

I would say your are safe to assume that such things do not occur. The
widely used idiom: sizeof array / sizeof *array relies on it, for one
thing.

--
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>I was going to say "yes" -- sizeof(char) is 1 and arrays can't have any
>padding between the elements -- but then I found I could not, at first
>reading, rule out arrays having padding after the last element. It

It is said, »When applied to an operand that has array type,
the result is the total number of bytes in the array.«
in »6.5.3.4 The sizeof operator« of »ISO/IEC 9899:1999 (E)«.

On 22-Feb-12 08:06, Ben Bacarisse wrote:
> Francois Grieu <fgrieu@gmail.com> writes:
>> I am wondering if (on a conforming hosted implementation of C99)
>> the following program is guaranteed to output: 3 3
>>
>> Specifically, I'm afraid that there could be some padding,
>> either for type foo, or variable bar.
>>
>> #include <stdio.h>
>> typedef char foo[3];
>> int main(void) {
>> foo bar;
>> printf("%u %u\n",(unsigned)sizeof(foo),(unsigned)sizeof bar);
>> return 0;
>> }
>
> I was going to say "yes" -- sizeof(char) is 1 and arrays can't have any
> padding between the elements

True. One should not forget that the array elements themselves may
contain padding, but that is extremely unlikely in this case.

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

On 22/02/2012 15:06, Ben Bacarisse wrote:
> Francois Grieu <fgrieu@gmail.com> writes:
>
>> I am wondering if (on a conforming hosted implementation of C99)
>> the following program is guaranteed to output: 3 3
>>
>> Specifically, I'm afraid that there could be some padding,
>> either for type foo, or variable bar.
>>
>> #include <stdio.h>
>> typedef char foo[3];
>> int main(void) {
>> foo bar;
>> printf("%u %u\n",(unsigned)sizeof(foo),(unsigned)sizeof bar);
>> return 0;
>> }
>
> I was going to say "yes" -- sizeof(char) is 1 and arrays can't have any
> padding between the elements -- but then I found I could not, at first
> reading, rule out arrays having padding after the last element. It
> would be daft, of course, but I can't see why it is not permitted.
>
> I would say your are safe to assume that such things do not occur. The
> widely used idiom: sizeof array / sizeof *array relies on it, for one
> thing.

Invoquing that idiom is an excellent idea. It is given in the standard
as 6.5.3.4 (6)
Another use of the sizeof operator is to compute the number of
elements in an array:
sizeof array / sizeof array[0]

Thus I'm ready to assume that after

char bot[3];

indeed sizeof(bot) is 3.


But does that tell us the size of the type foo or of the variable
bar [that would be the case if bar was an "array" in the sense
of 6.5.3.4 (6), but is it?

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>I was going to say "yes" -- sizeof(char) is 1 and arrays can't have any
>>padding between the elements -- but then I found I could not, at first
>>reading, rule out arrays having padding after the last element. It
>
> It is said, »When applied to an operand that has array type,
> the result is the total number of bytes in the array.«
> in »6.5.3.4 The sizeof operator« of »ISO/IEC 9899:1999 (E)«.

I don't think that helps. It does not say that the total number of
bytes in the array can't be a few more than the minimum required.

Two things do help. (1) Later in the same paragraph "trailing padding"
is explicitly referred to for struct types, so one can, I think, exclude
it for array types simply by the fact that it is *not* mentioned. (2)
The example in paragraph 6. Not normative by itself, but the intent is
made very clear.

--
Ben.

Francois Grieu <fgrieu@gmail.com> writes:

> On 22/02/2012 15:06, Ben Bacarisse wrote:
>> Francois Grieu <fgrieu@gmail.com> writes:
>>
>>> I am wondering if (on a conforming hosted implementation of C99)
>>> the following program is guaranteed to output: 3 3
>>>
>>> Specifically, I'm afraid that there could be some padding,
>>> either for type foo, or variable bar.
>>>
>>> #include <stdio.h>
>>> typedef char foo[3];
>>> int main(void) {
>>> foo bar;
>>> printf("%u %u\n",(unsigned)sizeof(foo),(unsigned)sizeof bar);
>>> return 0;
>>> }
>>
>> I was going to say "yes" -- sizeof(char) is 1 and arrays can't have any
>> padding between the elements -- but then I found I could not, at first
>> reading, rule out arrays having padding after the last element. It
>> would be daft, of course, but I can't see why it is not permitted.
>>
>> I would say your are safe to assume that such things do not occur. The
>> widely used idiom: sizeof array / sizeof *array relies on it, for one
>> thing.
>
> Invoquing that idiom is an excellent idea. It is given in the standard
> as 6.5.3.4 (6)
> Another use of the sizeof operator is to compute the number of
> elements in an array:
> sizeof array / sizeof array[0]

Yes, the intent is made 100% clear by that example.

> Thus I'm ready to assume that after
>
> char bot[3];
>
> indeed sizeof(bot) is 3.
>
>
> But does that tell us the size of the type foo or of the variable
> bar [that would be the case if bar was an "array" in the sense
> of 6.5.3.4 (6), but is it?

I can't see why not.

--
Ben.

Le 22/02/12 14:24, Francois Grieu a écrit :
> I am wondering if (on a conforming hosted implementation of C99)
> the following program is guaranteed to output: 3 3
>
> Specifically, I'm afraid that there could be some padding,
> either for type foo, or variable bar.
>
> #include<stdio.h>
> typedef char foo[3];
> int main(void) {
> foo bar;
> printf("%u %u\n",(unsigned)sizeof(foo),(unsigned)sizeof bar);
> return 0;
> }

The size is 3. Padding is of course there, but not in the array. Under
lcc-win the padding is inserted after the array, leaving a byte in the
stack unused, not a big deal this days.

"jacob navia" <jacob@spamsink.net> wrote in message
news:ji3ejc$oa9$1@speranza.aioe.org...
> Le 22/02/12 14:24, Francois Grieu a écrit :
>> I am wondering if (on a conforming hosted implementation of C99)
>> the following program is guaranteed to output: 3 3
>>
>> Specifically, I'm afraid that there could be some padding,
>> either for type foo, or variable bar.
>>
>> #include<stdio.h>
>> typedef char foo[3];
>> int main(void) {
>> foo bar;
>> printf("%u %u\n",(unsigned)sizeof(foo),(unsigned)sizeof bar);
>> return 0;
>> }
>
> The size is 3. Padding is of course there, but not in the array. Under
> lcc-win the padding is inserted after the array, leaving a byte in the
> stack unused, not a big deal this days.

What about in: foo bar[100]; ?

All the compilers I tried showed sizeof(bar) to be 300, so no padding
between elements, yet to me it would seem useful to round each entry up to 4
bytes: that makes it possible to copy an entire 3-byte entry to another
using 32-bit instructions, all the entries start on a preferred alignment,
and index calculation is simpler.

(However I'm not sure I'd be happy about a foo[33] element rounded up to
64...)

--
Bartc

On Wed, 22 Feb 2012 14:06:55 +0000, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

>Francois Grieu <fgrieu@gmail.com> writes:
>
>> I am wondering if (on a conforming hosted implementation of C99)
>> the following program is guaranteed to output: 3 3
>>
>> Specifically, I'm afraid that there could be some padding,
>> either for type foo, or variable bar.
>>
>> #include <stdio.h>
>> typedef char foo[3];
>> int main(void) {
>> foo bar;
>> printf("%u %u\n",(unsigned)sizeof(foo),(unsigned)sizeof bar);
>> return 0;
>> }
>
>I was going to say "yes" -- sizeof(char) is 1 and arrays can't have any
>padding between the elements -- but then I found I could not, at first
>reading, rule out arrays having padding after the last element. It
>would be daft, of course, but I can't see why it is not permitted.
>
>I would say your are safe to assume that such things do not occur. The
>widely used idiom: sizeof array / sizeof *array relies on it, for one
>thing.

Does changing the definition of bar to
foo bar[2]
and then applying 6.2.5-20 and 6.5.2.1-4 effectively eliminate the
possibility of "end of array padding"?

How about 6.5.3.4-3 which discusses sizeof applied to arrays? It
mentions internal and trailing padding for structure and union types
but not for arrays.

How about footnote 94 which talks about sub-arrays being adjacent?

--
Remove del for email

Le 22/02/12 15:06, Ben Bacarisse a écrit :
> Francois Grieu<fgrieu@gmail.com> writes:
>
>> I am wondering if (on a conforming hosted implementation of C99)
>> the following program is guaranteed to output: 3 3
>>
>> Specifically, I'm afraid that there could be some padding,
>> either for type foo, or variable bar.
>>
>> #include<stdio.h>
>> typedef char foo[3];
>> int main(void) {
>> foo bar;
>> printf("%u %u\n",(unsigned)sizeof(foo),(unsigned)sizeof bar);
>> return 0;
>> }
>
> I was going to say "yes" -- sizeof(char) is 1 and arrays can't have any
> padding between the elements -- but then I found I could not, at first
> reading, rule out arrays having padding after the last element. It
> would be daft, of course, but I can't see why it is not permitted.
>

Of course it is permitted. The padding bytes just aren't part of the
array!

Barry Schwarz <schwarzb@dqel.com> writes:

> On Wed, 22 Feb 2012 14:06:55 +0000, Ben Bacarisse
> <ben.usenet@bsb.me.uk> wrote:
>
>>Francois Grieu <fgrieu@gmail.com> writes:
>>
>>> I am wondering if (on a conforming hosted implementation of C99)
>>> the following program is guaranteed to output: 3 3
>>>
>>> Specifically, I'm afraid that there could be some padding,
>>> either for type foo, or variable bar.
>>>
>>> #include <stdio.h>
>>> typedef char foo[3];
>>> int main(void) {
>>> foo bar;
>>> printf("%u %u\n",(unsigned)sizeof(foo),(unsigned)sizeof bar);
>>> return 0;
>>> }
>>
>>I was going to say "yes" -- sizeof(char) is 1 and arrays can't have any
>>padding between the elements -- but then I found I could not, at first
>>reading, rule out arrays having padding after the last element. It
>>would be daft, of course, but I can't see why it is not permitted.
>>
>>I would say your are safe to assume that such things do not occur. The
>>widely used idiom: sizeof array / sizeof *array relies on it, for one
>>thing.
>
> Does changing the definition of bar to
> foo bar[2]
> and then applying 6.2.5-20 and 6.5.2.1-4 effectively eliminate the
> possibility of "end of array padding"?

I don't think so. Both of those apply equally to

struct { char a[3]; } sa[2];

and we know that the sizeof sa[0] need not be 3.

> How about 6.5.3.4-3 which discusses sizeof applied to arrays? It
> mentions internal and trailing padding for structure and union types
> but not for arrays.

Yes, that's enough for me, though it's a shame it's a demonstration by
omission.

> How about footnote 94 which talks about sub-arrays being adjacent?

For me, no. If the supposed padding is part of the array (like it is
with a struct) the arrays are still adjacent.

--
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>I don't think that helps. It does not say that the total number of
>bytes in the array can't be a few more than the minimum required.

There is:

»There may be unnamed padding at the end of a
structure or union.« 6.7.2.1p15, ISO/IEC 9899:1999 (E)

But no such license is given for an array.

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>I don't think that helps. It does not say that the total number of
>>bytes in the array can't be a few more than the minimum required.
>
> There is:
>
> »There may be unnamed padding at the end of a
> structure or union.« 6.7.2.1p15, ISO/IEC 9899:1999 (E)
>
> But no such license is given for an array.

Yes, as I've already said, I think that silence is the strongest
argument. That and the explicit example of dividing the array size by
the element size to get the length.

--
Ben.