Hat, ugye mi a helyzet. Ha van egy ilyen kodod, mint pl:
struct whatever1
{ uint32_t data;
};
/* LSB */
struct whatever2
{ unsigned int next_bits: 17;
unsigned int interesting: 4;
unsigned int prev_bits: 11;
};
struct whatever1 *w1;
struct whatever2 *w2;
w2->interesting = value;
w1->data = ((w1->data) & (~ (((1<<4)-1))<<17 )) | ((value&((1<<4)-1))<<17);
akkor minden jolnevelt C fordito (lenyegeben es/vagy teljesen) ugyanazt csinalja a ket kodbol. Es ez konkretan tapasztaltam is, legalabbis beagyazott cuccoknal ahol deployment elott atnezem az asm reszek kritikusabb reszeit neha (AVRx, ARMv6-M), es mindenhol - ahol nem is nezem at az asm-et - a ketto ugyanazt csinalja, es a sizeof(struct whatever2) ugyanugy 4. Vagyis, mindenhol, kiveve XC8-nal. Ahol a w1->data bit juggling tenyleg azt csinalja amit varunk, de nem lehet az egyszerubb w2->... ertekadast hasznalni. Es ebben a fenti use case-ban az AVRx az ugyanolyan 8 bites mert az X/Y/Z indexinget nem hasznalod ki sehol (max az ld/st-resznel, hogy mondjuk Z-ben van a pointer). PIC-nel meg ha a w1->data zsonglorkodesbol is tok jo kod tud keletkezni (kiprobaltam, mukodik, hasznaljuk), bankolas ide vagy oda, akkor azt a sima bitfieldnel miert nem lehetett...
Na mindegy, szoval persze, az sajnos lehet egy valid megoldas az egesz kerdesre hogy "a bitfieldek nem definialtak, oszt jonapot", "meg oldd meg ahogy tudod", de... akkor mar az ennyire custom/proprietary C-nel mint az XC8 inkabb dobjon forditasi hibat a bitfieldre minthogy a de facto standardokat ne tudja :/