Hi, I get a curious result when compiling such a following code :
typedef union { unsigned char cCtrlFullByte; struct { unsigned char bEnable : 1; unsigned char cUnused : 7; } cCtrlStruct; } CtrlUnion; void main (void) { unsigned char dummy = 0x55; CtrlUnion xdata bitUnion; bitUnion.cCtrlStruct.bEnable = dummy & 0x40; return; }
MOV A,#0x55 ANL A,#0x00 MOV R7,A MOV DPTR, #0x0000 MOVX A,@DPTR ANL A,#0xFE ORL A,R7 MOVX @DPTR, A
I recently invented this macro to access Bits in a Byte:
#define BITREF(aByte,aPos)((struct {unsigned char _0:1;unsigned char _1:1;unsigned char _2:1;unsigned char _3:1;unsigned char _4:1;unsigned char _5:1;unsigned char _6:1;unsigned char _7:1;}*)&aByte)->_##aPos
byte xdata b; BITREF(b,4) = 1; BITREF(b,7) = BITREF(b,4);
Variables with leading underscores are reserved for use by the implentation. As are functions starting with 'str'. Be aware. - Mark
I'm aware. These aren't really variables. I dont see any possibility for an implementation to interfere with _mbr in:
struct {some_type_here _mbr;} variable;
If I write a compiler and have some internal _mbr variable used in one of my libraries it would be within my right. Then you'd have a problem. My point is, never use _ as a leading char in anything. It's just safer. - Mark