c - bit store order in memory -

x86 machine, os: linux 2.6 rh. here codes:

    #include "stdio.h"     typedef struct ch_t     {         int c0:1;         int c1:1;         int c2:1;         int c3:1;         int c4:1;         int c5:1;         int c6:1;         int c7:1;     } ch;      typedef union chh_u     {         char a;         ch chat;     } chh;     int main(void)     {         chh uu;         uu.a = 6;         printf("\n%d", uu.chat.c0);         printf("\n%d", uu.chat.c1);         printf("\n%d", uu.chat.c2);         printf("\n%d", uu.chat.c3);         printf("\n%d", uu.chat.c4);         printf("\n%d", uu.chat.c5);         printf("\n%d", uu.chat.c6);         printf("\n%d", uu.chat.c7);         printf("\n%d\n", uu.a);         return 0;     } 

as expected, output should be:

0 0 0 0 0 1 1 0 6

but actual output was:

0 -1 -1 0 0 0 0 0 6

i can't understand why output above. think 6 bit order 0000 0110, , in memory, in option, bit order 0000 0110. output shows difference.

can 1 explain this?

the relevant parts of standard 6.7.2 (5).

each of comma-separated sets designates same type, except bit-fields, implementation-defined whether specifier int designates same type signed int or same type unsigned int.

...this explains why (can) -1 instead of 1 set bits. other 6.7.2.1 (10):

an implementation may allocate addressable storage unit large enough hold bit-field. if enough space remains, bit-field follows bit-field in structure shall packed adjacent bits of same unit. if insufficient space remains, whether bit-field not fit put next bits or overlaps adjacent units implementation-defined. the order of allocation of bit-fields within unit (high-order low-order or low-order high-order) implementation-defined. alignment of addressable storage unit unspecified.

so that, too, go either way.

addendum: since there appears confusion this: calling function variable argument list bit-fields fine if function expects int inside, same reasons fine say

char c = '\xff'; printf("%d\n", c); // print 255 or -1 

and can give different results precisely same reasons, because bit-field, char can signed or unsigned depending on implementation. i'll quote relevant bits irrelevant parts cut out time because these rules buried in tediously legalese parts of c99 standard. found in 6.5.2.2 (6):

if expression denotes called function has type not include prototype, the integer promotions performed on each argument, , arguments have type float converted double. these called default argument promotions. (...)

and 6.5.2.2 (7):

(...) ellipsis notation in function prototype declarator causes argument type conversion stop after last declared parameter. the default argument promotions performed on trailing arguments.

the integer promotions defined in 6.3.1.1; relevant bit in paragraphs 2 , 3:

2 following may used whereever int or unsigned int may used:

• (...)
• a bit-field of type _bool, int, signed int or unsigned int.

if int can represent values of original type, value converted int; otherwise, converted unsigned int. (...)

3 integer promotions preserve value including sign. (...)

so, happens:

1. your compiler treats int bit-fields signed
2. this means bit-field of width 1 bit set has value -1; is, in manner of speaking, sign, , set.
3. in passing printf converted, preserving value, int
4. this int printed printf according %d format string , gives "-1".
5. profit?