Comments on: Bit-fields in C99 http://blog.reverberate.org/2009/06/26/bit-fields-in-c99/ parsing, performance, minimalism with C99 Mon, 06 Feb 2012 23:44:51 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Someone http://blog.reverberate.org/2009/06/26/bit-fields-in-c99/comment-page-1/#comment-1358 Someone Mon, 29 Jun 2009 20:09:50 +0000 http://blog.reverberate.org/?p=168#comment-1358 "struct foo { unsigned int a:1; unsigned int b:2; } …will always be packed into a single byte. sizeof(struct foo) could be greater than 1, but you are guaranteed that a and b are in the same byte." On the other hand, the way I read "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" would mean that "struct foo { unsigned int a:7; unsigned int b:7; unsigned int c:2; } can take 3 bytes. <i>Aside: the preview shows backslashes before every double-quote. I hope these will disappear after submitting this comment.</i> “struct foo {
unsigned int a:1;
unsigned int b:2;
}

…will always be packed into a single byte. sizeof(struct foo) could be greater than 1, but you are guaranteed that a and b are in the same byte.”

On the other hand, the way I read “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” would mean that

“struct foo {
unsigned int a:7;
unsigned int b:7;
unsigned int c:2;
}

can take 3 bytes.
Aside: the preview shows backslashes before every double-quote. I hope these will disappear after submitting this comment.

]]> By: Jeremy http://blog.reverberate.org/2009/06/26/bit-fields-in-c99/comment-page-1/#comment-1356 Jeremy Sat, 27 Jun 2009 19:43:04 +0000 http://blog.reverberate.org/?p=168#comment-1356 This is similar to a technique that is often used for accessing bit-fields of a hardware addressable register. Some interesting comments relating to this were posted at RegisterBits: http://www.registerbits.com/bit-field-struct-union-c-firmware . It seems that there are various concerns wrt non-portability of this seemingly elegant technique. Namely bit-field ordering, memory alignment, endianess, compiler dependency,... If you don't need to make the structure fit with some memory mapped hardware, then it should be a lot less of a concern so long as same compiler packs/unpacks the struct. Even if the same compiler is used, the structure may look different in memory for different processor endiannesses. Any serialization or tx/rx of the structure could cause issues too, I suppose (network ordering). This is similar to a technique that is often used for accessing bit-fields of a hardware addressable register. Some interesting comments relating to this were posted at RegisterBits: http://www.registerbits.com/bit-field-struct-union-c-firmware .

It seems that there are various concerns wrt non-portability of this seemingly elegant technique. Namely bit-field ordering, memory alignment, endianess, compiler dependency,…

If you don’t need to make the structure fit with some memory mapped hardware, then it should be a lot less of a concern so long as same compiler packs/unpacks the struct. Even if the same compiler is used, the structure may look different in memory for different processor endiannesses. Any serialization or tx/rx of the structure could cause issues too, I suppose (network ordering).

]]>