tags:

views:

195

answers:

6

In the following piece of code,

#include<stdio.h>
typedef struct {
    int bit1:1;
    int bit3:4;
    int bit4:4;
} node;

int main(){
    node n,n1,n2,ff[10];

    printf("%d\n",sizeof(node));
    return 0;
}

How do I predict the size of the structure?

+8  A: 

You cannot predict it without knowing the compiler and the target platform it compiles to.

Johannes Schaub - litb
@Johannes, tell them why.
Nikolai N Fetissov
A: 

Usually every compiler decides how to pack the union so you can't make many assumptions on the final size. They can decide a different layout according to its parameters.

Jack
+3  A: 

It depends on the platform and the compiler settings (packing, alignment, 32/64 machine)

According to comp.lang.c FAQ list

"Bit-fields are thought to be nonportable, although they are no less portable than other parts of the language."

stacker
what a weird quote...
jalf
+1  A: 

You will find that the size of your structure changes based on compiler optimization settings. I'd predict anywhere between 2 and 12 bytes for this structure.

Even when using bit-fields like you do, you can't always predict what the size of a struct is going to be. The compiler may have every bit-field take up the full space of an int, or possibly just the 1 or 4 bits that you specify. Using bit-fields, while it is great on memory storage space, is often bad for running time and executable size.

Mike
I'm not sure it would be legal for the compiler to have this structure occupy less than the size of an int. It certainly can't occupy less than the size of a char, since sizeof(...) must return an integer.
Stewart
@Stewart: There are platforms on which `sizeof(int) == 2`.
Stephen Canon
@Stephen: I don't think I said there weren't. There are also platforms where it is not a multiple of eight bits, and nothing in my answer disallows that either. The answer suggests the compiler may pack the structure into only 4 bits, that is what I was saying can't happen, particularly as an int must be at least 16 bits.
Stewart
@Stewart, no he said that each bitfield might occupy as little space as it is declared to in some cases. And that is true, although since this example declares a total of 9 bits, it is extremely likely that any modern platform will also have some padding bits to make the whole thing fit in an integral number of `char`. On common platforms, 2 is a plausible size, but 4 is more likely. 12 is certainly possible since there are 3 declared fields and a (foolish?) speed optimization could assign each to its own 32-bit `int`.
RBerteig
the smallest this could ever be is 2 bytes, (assuming you're restricting to platforms with 8 bit bytes.. there are some with 9 bit bytes, but I don't know if anyone still uses them, or if C compilers exist for them... in that case it could be 1 byte) the reason for this is that if you declare an array of these the individual elements must be addressable and I don't think there's ever been an architecture where you can address anything smaller than the platform's byte.
Spudd86
Note: I don't think there are any of those platforms with 9 bit bytes that any cares about anymore (I think they were mostly pre 90's systems...)
Spudd86
@RBerteig an integral number of the smallest addressable unit is guaranteed but like I said above, some machines have weird sized bytes
Spudd86
It's extraordinarily unlikely that the layout of a `struct` would change with different optimisation settings, because this would make code compiled with different optimisations settings binary incompatible - which is not usually considered a good thing.
caf
@caf, most compilers provide control over structure packing, which can be used as an optimization that trades memory size for speed in some architectures, while raising the potential for breaking ABI compatibility with libraries and other modules. See the commonly implemented `#pragma pack` for an example.
RBerteig
@spudd86, I was trying (possibly poorly) to draw attention to the fact that the implementation has some choices it can make about which bytes to use for each of the several bitfields. Common implementations will allocate them as adjacent bits in a single integral type value, but if assigned in order from low bit to high bit, that would make the third field span a (8-bit) byte boundary which might trigger padding. It is hard enough to guess a structure's size without bitfield members...
RBerteig
@RBerteig: That's an explicit programmer request for different packing, which is a different kettle of fish to structure packing being implicitly changed by the normal optimisation settings (which is what the answer implied, at least to this reader).
caf
+2  A: 

Unpredictable in general, but practically speaking it'll come out sizeof(int) more often than not. Which itself is very often 4; less commonly 2 and surely 8 at times.

Most of the time the bit fields will be packed and most of the time the int type will have 9 or more bits of storage.

George Phillips
int is always at least 16 bits, the standard says so (long is always at least 32, and in C99 we get long long which is at least 64, and they can all be bigger than those sizes)
Spudd86
A: 

Add the bit-field sizes, divide by 8*sizeof(int), and take the ceiling of that value. In your example, it'll be 4.

John
That has no underlying logic whatsoever...
SurDin
@SurDin The assumption is the compiler packs the fields tightly and uses blocks of size sizeof(int).
Spudd86