Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > what's the size of type char foo[3] ?

Reply
Thread Tools

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

 
 
Francois Grieu
Guest
Posts: n/a
 
      02-22-2012
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;
}
 
Reply With Quote
 
 
 
 
Stefan Ram
Guest
Posts: n/a
 
      02-22-2012
Francois Grieu <(E-Mail Removed)> 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).

 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      02-22-2012
Francois Grieu <(E-Mail Removed)> 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.
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      02-22-2012
Ben Bacarisse <(E-Mail Removed)> 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)«.

 
Reply With Quote
 
Stephen Sprunk
Guest
Posts: n/a
 
      02-22-2012
On 22-Feb-12 08:06, Ben Bacarisse wrote:
> Francois Grieu <(E-Mail Removed)> 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
 
Reply With Quote
 
Francois Grieu
Guest
Posts: n/a
 
      02-22-2012
On 22/02/2012 15:06, Ben Bacarisse wrote:
> Francois Grieu <(E-Mail Removed)> 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?
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      02-22-2012
http://www.velocityreviews.com/forums/(E-Mail Removed)-berlin.de (Stefan Ram) writes:

> Ben Bacarisse <(E-Mail Removed)> 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.
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      02-22-2012
Francois Grieu <(E-Mail Removed)> writes:

> On 22/02/2012 15:06, Ben Bacarisse wrote:
>> Francois Grieu <(E-Mail Removed)> 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.
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      02-22-2012
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.
 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      02-22-2012


"jacob navia" <(E-Mail Removed)> wrote in message
news:ji3ejc$oa9$(E-Mail Removed)...
> 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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
(const char *cp) and (char *p) are consistent type, (const char **cpp) and (char **pp) are not consistent lovecreatesbeauty C Programming 1 05-09-2006 08:01 AM
/usr/bin/ld: ../../dist/lib/libjsdombase_s.a(BlockGrouper.o)(.text+0x98): unresolvable relocation against symbol `std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostre silverburgh.meryl@gmail.com C++ 3 03-09-2006 12:14 AM
char *fred; char * fred; char *fred; any difference? Ben Pfaff C Programming 5 01-17-2004 07:37 PM
The difference between char a[6] and char *p=new char[6] ? wwj C Programming 24 11-07-2003 05:27 PM
the difference between char a[6] and char *p=new char[6] . wwj C++ 7 11-05-2003 12:59 AM



Advertisments