Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #63530

Re: What is the output of this program ?

Show all headers | View raw

On 06/18/2015 09:45 AM, Rahul Kumar wrote:
> #include <stdio.h>
> 
> struct s
> {
> 	int a:4;
> 	char b:5;
> 	int c:7;
> 	unsigned f1:1;
> 	unsigned f2:24;
> 	unsigned :3;
> 	int :3;// anonymous b.f. -- not accessible
> 	int :0;	// significance -- align to next word boundary -- 47 bit < 64 bit -- align to 64 bit(8byte)
> 	unsigned f3:6;	// 70 bit
> 	unsigned :0; 	// ????? -- 96
> 	unsigned f4:8;	//104 -- 13 byte -- 16 byte size
> }x;
> 
> int main()
> {
> 	printf("%d\n",sizeof(x));
> }
> 
> how to calculate output of this program,please help me,i am just confused with it.

My first answer was correct, but not particularly detailed. I'll give
you some more details this time.

As Richard has already mentioned, a compiler is not required to accept a
bit-field of type 'char', so this code can only be ported to compilers
that accept that type.
A bit-field width is not allowed to exceed the size in bits of the
corresponding type. Therefore, the declaration of f2 is allowed only on
implementations where "unsigned int" has at least 24 bits.

It is implementation-defined whether a bit-field of type 'int' has a
signed or unsigned type. Since it's almost never a good idea to be
unsure whether a type is signed or unsigned, I recommend replacing "int"
with "signed int" (or, more simply, "signed") in all of the above member
declarations. The same is probably true for any implementation that
allows bit-fields of "char" type. I recommend explicitly declaring "b"
as either "signed char" or "unsigned char", depending upon what you
actually want it to be.

"There may be unnamed padding within a structure object, but not at its
beginning." (6.7.2.1p15). Note that there is no upper limit on the
amount of padding. This is the key thing that makes it impossible to
"calculate" the size of this struct.

In practice, most implementations will align a struct with the strictest
alignment of any of it's members, and align each individual member
according to the alignment requirements of it's type. They will
introduce padding between members only as needed to ensure correct
alignment. The size of a struct must be a multiple of alignment
requirement for the struct, and most implementations will put padding at
the end of a struct only if needed for that purpose. However, you
shouldn't write code that relies upon these things.

If you're using C2011, you can use _Alignof(type) to find out the
alignment requirements for a type, and you can use _Alignas() to impose
stricter alignment requirements on an object than would otherwise apply.
In older versions of C, the only way to find out about such things was
to read the documentation for the compiler.

6.7.2.1p11 says:
> An implementation may allocate any addressable storage unit large enough to hold a bitfield.
> If enough space remains, a bit-field that immediately follows another bit-field in a
> structure shall be packed into adjacent bits of the same unit. If insufficient space remains,
> whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is
> implementation-defined. The order of allocation of bit-fields within a unit (high-order to
> low-order or low-order to high-order) is implementation-defined. The alignment of the
> addressable storage unit is unspecified.

Note that this implies that padding bytes are not permitted between
addressable storage units (ASU). If there's enough space to put the next
bit-field in the same ASU as the previous one, it must be put there. If
there isn't enough room, the implementation has a choice, but only
between two options: a) putting part of the bit-field in the same ASU,
and the rest of it in the next one or b) putting it entirely in the next
ASU. Either way, there's no room for padding bytes between the ASUs.
There might be more than CHAR_BIT consecutive padding bits within an
ASU, but only if the next struct member is not a bit-field small enough
to fit in the available bits.

Because the implementation does get to make that choice, and also
because it gets to choose the size and alignment requirements of the
ASU, there's still considerable freedom for different implementations to
give different sizes to the same struct, even if every member is
bit-field, even though that means that padding bytes between members are
not allowed.

Finally, even if the size of the struct in bits were completely
specified, the value returned by "sizeof x" would depend upon the value
of CHAR_BIT from <limits.h>.

The comments in the struct imply that it was written by someone who
knows about 6.7.2.1p12 - but if it wasn't written by you, you might need
to know this in order to understand what they wrote:

"A bit-field declaration with no declarator, but only a colon and a
width, indicates an unnamed bit-field. As a special case, a bit-field
structure member with a width of 0 indicates that no further bit-field
is to be packed into the unit in which the previous bitfield,
if any, was placed."

Lets examine one of the possibilities. Assume that the ASU has a size
and alignment requirement of 16, and that bit fields which don't fit
always are allocated to the next ASU. Then:

The first ASU will contain a(4 bits) b(5 bits) and c(7 bits). The order
of these fields within the ASU is unspecified.
The next ASU will contain only f1.
f2(24 bits) will be split between the third and fourth ASUs, followed by
the two unnamed bit-fields (3 bits each). How much of f2 will be placed
in the first ASU is unspecified - it could be as little as 14 bits, or
as much as 16 bits. Having two consecutive unnamed bit-fields seems odd
to me. It's not entirely pointless - whether those fields will be split
up or put in the same ASU will depend upon the size of the ASU.
f3(6 bits) will be put in the fifth ASU, and because of the bit-field
with a length of 0, f4(8 bits) will have to be put in the sixth
bit-field, for a total size of 6 ASUs * 16 bits/ASU = 96 bits. If
CHAR_BIT == 8, then sizeof(x) will be 12.

Note that this layout is inconsistent with the comments in the code. I
suspect that those comments were based upon the assumption that the ASU
had a size of 32 bits, rather than 16, neatly demonstrating why there's
no single answer to your question.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

What is the output of this program ? Rahul Kumar <rahulkumar5july@gmail.com> - 2015-06-18 06:45 -0700
  Re: What is the output of this program ? James Kuyper <jameskuyper@verizon.net> - 2015-06-18 10:10 -0400
  Re: What is the output of this program ? Richard Heathfield <rjh@cpax.org.uk> - 2015-06-18 15:22 +0100
    Re: What is the output of this program ? Keith Thompson <kst-u@mib.org> - 2015-06-18 08:07 -0700
      Re: What is the output of this program ? Richard Heathfield <rjh@cpax.org.uk> - 2015-06-18 16:11 +0100
    Re: What is the output of this program ? Ralf Damaschke <rwspam@gmx.de> - 2015-06-18 18:48 +0000
      Re: What is the output of this program ? Richard Heathfield <rjh@cpax.org.uk> - 2015-06-18 23:01 +0100
    Re: What is the output of this program ? Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:31 -0700
      Re: What is the output of this program ? jadill33@gmail.com - 2015-07-13 07:51 -0700
        Re: What is the output of this program ? Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 02:51 -0700
          Re: What is the output of this program ? jadill33@gmail.com - 2015-07-15 05:55 -0700
            Re: What is the output of this program ? Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 10:01 -0700
      Re: What is the output of this program ? Richard Heathfield <rjh@cpax.org.uk> - 2015-07-13 22:07 +0100
        Re: What is the output of this program ? Keith Thompson <kst-u@mib.org> - 2015-07-13 14:16 -0700
        Re: What is the output of this program ? Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 02:11 -0700
          Re: What is the output of this program ? Richard Heathfield <rjh@cpax.org.uk> - 2015-07-15 10:58 +0100
            Re: What is the output of this program ? Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 10:05 -0700
  Re: What is the output of this program ? James Kuyper <jameskuyper@verizon.net> - 2015-06-18 12:26 -0400
    Re: What is the output of this program ? Keith Thompson <kst-u@mib.org> - 2015-06-18 10:14 -0700

csiph-web