Re: incorrect handling of bit fields

Tech-Archive recommends: Speed Up your PC by fixing your registry


Doug Harrison [MVP] wrote:
> >Any ideas? For anything <= 8 bits, I can just use unsigned char, the
> >problem comes in when trying to represent a 12 bit integral value. I
> >seem to be stuck currently with just storing two unsigned char fields,
> >one 8 bit one 4 bit and then assembling them together with code.
>
> What were you expecting, and why? Bitfields are inherently non-portable,
> and you can't expect f3 and f4 to reside in the same machine word. However,
> the VC docs suggest that if you make f4 unsigned int, they will:
>
> http://msdn2.microsoft.com/en-us/library/hx1b6kkd.aspx
> <q>
> Adjacent bit fields are packed into the same 1-, 2-, or 4-byte allocation
> unit if the integral types are the same size and if the next bit field fits
> into the current allocation unit without crossing the boundary imposed by
> the common alignment requirements of the bit fields.
> </q>

What I'm expecting is to be able to address a 12-bit integral value in
a memory structure. The reason is that I'm receiving this structure
from an external hardware and its controlling the format of the data
coming in. The messages this device sends contain, for example, 12-bit
integral fields, so I needed some way to refer to this. I don't want
the compiler to do any padding, i.e., if I create a struct with a
12-bit int and then a 4 bit char, I'd like the result to be 2 bytes.
This is necessary to match the data coming in and avoid hand
re-assembling the data later.

> Note: Although you didn't indicate it, you must be using a packing option
> to get those sizes; please don't use /Zp for this, as you're liable to mess
> up other structs that expect default packing to be in effect.

I was using #pragma pack (1) before the struct definitions in the
module where this is an issue. This avoids putting unnecessary padding
bytes between fields, but it doesn't prevent taking what I've asked to
be a 12-bit integral value and stretching it out to 32 bits.

.