tags:

views:

280

answers:

2

I have a code which uses bit-fields declared as follows

typedef struct my{
    const char *name;
    uint8_t is_alpha : 1;   
    uint8_t is_hwaccel : 1; 
    uint8_t x_chroma_shift; 
    uint8_t y_chroma_shift; 

} mystr; 

uint8_t is typedef'ed to unsigned char.

Building the code in MS-VS 2008 using this bit fields gives a warning as below:

imgconvert.c(60) : warning C4214: nonstandard extension used : bit-field types other than int.
  1. Is there any problems/potential issues in using bit fields of type other than int? Why the warning?
  2. Are other than int type bit-fileds they allowed by C99 C language specification?
+3  A: 

1] Is there any problems/potential issues in using bit fields of type other than int? Why the warning?

Since bit-fields are low-level, there may be issues with portability if you are using non-standard types. Hence the warning -- note it is still a warning and not an error.

2] Are other than int type bit-fileds they allowed by C99 C language specification?

From the draft of C99:

6.7.2.1 Structure and union specifiers

4 A bit-field shall have a type that is a qualified or unqualified version of _Bool, signed int, unsigned int, or some other implementation-defined type.

dirkgently
Isn't "some other implementation-defined type" remarkably useless in a standards document?
anon
@Neil Butterworth: ATM, I just have the draft. Will need to look up the actual though. But, yes, I guess you are right.
dirkgently
@dirkgently: Using type int is useful from portability aspects only if all targets/compiler are guaranteed to have same sized ints. Is this a reasonable assumption. I dont know thats why i am asking.
goldenmean
@goldenmean: No, the standard gurantess only `char` to have the same size across all machines. The size of an `int`is defined only as a range so it's not very useful from the portability perspective. The `stdint` header was added for this purpose to C99. I guess you should be okay with the warning.
dirkgently
@dirkgently, sizeof(char) is one, but that doesn't mean CHAR_BIT is the same on all platforms.
AProgrammer
@Neil, assuming there is an implementation for which they are valid, those words makes a program which use another types conforming (conforming, not strictly conforming).
AProgrammer
@goldenmean: `int` is portable, even on platforms with other sized `int`s. When dealing with bitfields, the compiler could pack them into a single `int` or give them their own `int`.If you're trying to create a struct to match a file format or protocol format, don't use bitfields.
tomlogic
@Neil: I don't think so. While I personally prefer languages that have a stricter definition than that, I see the use in allowing implementations to support other types as well. The ones mentioned here are the ones that every implementation *must* support.
Joachim Sauer
@dirkgently: TI's C55xx compiler's char type for example is 16 bit. sizeof(char) is 1 as required by teh standard, but CHAR_BIT is 16. The architecture does not support 8-bit addressability. Makes porting third-party code a pain.
Clifford
A: 

Why not use int? The actual implementation of bitfields varies from compiler to compiler. If you want to write portable code, use int. If you want to create a small structure, or a structure of a fixed number of bytes, or a structure where the bits are in a fixed position, don't use bitfields. Create a uint8_t member called something like flags and define macros to use as bitmasks.

tomlogic
You mean `unsigned int`. `uint8_t` is unsigned, `int` is signed, mixing them is no good.
KennyTM
I haven't personally used bitfields in code, but if it's a 1-bit bitfield, does the sign matter?
tomlogic