Thread: Parity check

Well that's a woefully inadequate description of bit-fields. The examples are pretty much guaranteed to only work on the (unspecified) implementation which the author tried them on.

Code:

struct bmap{              /* bitfields for 8 bit byte  */
        unsigned bit7:1;  /* 8 bit char  */
        unsigned bit6:1;
        unsigned bit5:1;
        unsigned bit4:1;
        unsigned bit3:1;
        unsigned bit2:1;
        unsigned bit1:1;
        unsigned bit0:1;
};
int main ( void ) {
    printf( "%ld\n", sizeof(struct bmap) );
    return 0;
}

First compiler I tried, it printed 4

If you want standards, try this
Section 6.7.2 of the free one

Code:

       [#9] An implementation may allocate any addressable  storage
       unit  large  enough  to  hold  a bit-field.  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.

It only has to be large enough - there is nothing about being exactly small enough.

If you want small, then you have to use implementation specific "pack" pragmas, attributes or whatever else your compiler provides.

Originally Posted by quzah

You could have just compiled it. I was going to do this...

Code:

unsigned char OxOO( unsigned int Ox0O )
{
        int OxO0,Ox00;
        for( OxO0=Ox00=0x00;OxO0<sizeof(unsigned int)*CHAR_BIT;OxO0=OxO0+0x01 )
                Ox00=Ox00+(!!(Ox0O&(0x01<<OxO0)));
        return Ox00;
}

Quzah.

I love it!!! Here compile this. Just don't try to read it.

The size of a char (in terms of the number of bits) doesn't matter, since it has no bearing on the underlying "storage unit" in which bit-fields are stored (that's the quote that I posted), so long as that underlying "storage unit" is big enough to hold those bits.

Sure the bits in your structure occupy 8 consecutive bits of a bit-field "storage unit" (because unsigned char must have at least 8 bits - your argument), that much is guaranteed at least (that's the adjacency rule in my quote).
But there's nothing to stop an implementation stuffing those bits in a 32 bit integer (as my implementation does). Whether they occupy bits 0..7 or bits 24..31 is again implementation specific, so your chances of success are only 50%.

That's what "any addressable storage unit" means. An unsigned int is an addressable storage unit, so my implementation is free to choose it.
By the way, gcc and vc++ both give the answer 4
Care to chip in with some compilers which give the answer 1 without resorting to even more implementation specific tweaks.

The only thing your argument proves is that given a "unsigned bit:1" is that it will have the values 0 or 1 (the representation of bit-fields will be pure binary). It says nothing about the underlying storage unit used to store those bits. It certainly has no bearing on the number of padding bits which an implementation can add, so long as the adjacency rule is followed.

Besides which, since it has already been pointed out by others, CHAR_BIT is only required to be at LEAST 8, not exactly 8.

Please don't dig up old threads, just create a new one specific to your problem and with more details.