449,074 Members | 1,002 Online
Need help? Post your question and get tips & solutions from a community of 449,074 IT Pros & Developers. It's quick & easy.

bitfield and enum, is this legal?

 P: n/a Hi group! Is this code legal? typedef enum { FALSE = 0, TRUE = 1, }t_bool; typedef struct { t_bool b0 : 1, b1 : 1, b2 : 1, b3 : 1, b4 : 1, b5 : 1, b6 : 1, b7 : 1; }t_bitfield8; //Erik Nov 14 '05 #1
8 Replies

 P: n/a er*******@japro.se (Erik Cato) writes: Is this code legal? typedef enum { FALSE = 0, TRUE = 1, }t_bool; typedef struct { t_bool b0 : 1, b1 : 1, b2 : 1, b3 : 1, b4 : 1, b5 : 1, b6 : 1, b7 : 1; }t_bitfield8; It's not portable. Bit-fields can only portably have type signed int or unsigned int. -- "This is a wonderful answer. It's off-topic, it's incorrect, and it doesn't answer the question." --Richard Heathfield Nov 14 '05 #2

 P: n/a Ben Pfaff wrote in message news:<87************@pfaff.stanford.edu>... er*******@japro.se (Erik Cato) writes: Is this code legal? typedef enum { FALSE = 0, TRUE = 1, }t_bool; typedef struct { t_bool b0 : 1, b1 : 1, b2 : 1, b3 : 1, b4 : 1, b5 : 1, b6 : 1, b7 : 1; }t_bitfield8; It's not portable. Bit-fields can only portably have type signed int or unsigned int. Or _Bool in C99. Note that 'plain' int is also allowed, but it is implementation defined as to whether this behaves as signed or unsigned int in the context of bitfields. -- Peter Nov 14 '05 #3

 P: n/a ai***@acay.com.au (Peter Nilsson) writes: Ben Pfaff wrote in message news:<87************@pfaff.stanford.edu>... It's not portable. Bit-fields can only portably have type signed int or unsigned int. Or _Bool in C99. I thought about adding that, but then I decided that C99 was also not portable :-) Nov 14 '05 #4

 P: n/a On Mon, 23 Feb 2004 09:46:36 -0800, Ben Pfaff wrote in comp.lang.c: er*******@japro.se (Erik Cato) writes: Is this code legal? typedef enum { FALSE = 0, TRUE = 1, }t_bool; typedef struct { t_bool b0 : 1, b1 : 1, b2 : 1, b3 : 1, b4 : 1, b5 : 1, b6 : 1, b7 : 1; }t_bitfield8; It's not portable. Bit-fields can only portably have type signed int or unsigned int. No, it is undefined behavior under any version of the standard prior to C99. Semantics section of 6.5.2.1 of C90/95: A bit-field shall have a type that is a qualified or unqualified version of one of int, unsigned int, or signed int. Whether the high-order bit position of a (possibly qualified) “plain” int bit-field is treated as a sign bit is implementation-defined. A bit-field is interpreted as an integral type consisting of the specified number of bits. The result of violating a "shall" outside of a constraint clause is undefined behavior. -- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html Nov 14 '05 #5

 P: n/a On 23 Feb 2004 04:55:53 -0800, er*******@japro.se (Erik Cato) wrote in comp.lang.c: Hi group! Is this code legal? typedef enum { FALSE = 0, TRUE = 1, }t_bool; typedef struct { t_bool b0 : 1, b1 : 1, b2 : 1, b3 : 1, b4 : 1, b5 : 1, b6 : 1, b7 : 1; }t_bitfield8; //Erik It is undefined behavior prior to the C99 standard update and allowed as an implementation-defined extension in C99. The behavior of single bit bit-fields not defines specifically as unsigned is very much implementation defined. Any field where the bit is set to 1 might be promoted to the integer value -1, rather than +1, in expressions. -- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html Nov 14 '05 #6

 P: n/a Jack Klein writes: On Mon, 23 Feb 2004 09:46:36 -0800, Ben Pfaff wrote in comp.lang.c: er*******@japro.se (Erik Cato) writes: It's not portable. Bit-fields can only portably have type signed int or unsigned int. No, it is undefined behavior under any version of the standard prior to C99. Semantics section of 6.5.2.1 of C90/95: Relying on undefined behavior is nonportable. -- "The fact that there is a holy war doesn't mean that one of the sides doesn't suck - usually both do..." --Alexander Viro Nov 14 '05 #7

 P: n/a > > typedef enum { FALSE = 0, TRUE = 1, }t_bool; typedef struct { t_bool b0 : 1, .... }t_bitfield8; It is undefined behavior prior to the C99 standard update and allowed as an implementation-defined extension in C99. What is the difference between these two cases. If the standard calls something "undefined" then the implementation is allowed to define it anyway. And if it is "allowed as an ID extension" but the extension is not provided, then it is UB. Nov 14 '05 #8

 P: n/a On 25 Feb 2004 13:26:34 -0800, ol*****@inspire.net.nz (Old Wolf) wrote: > typedef enum > { > FALSE = 0, > TRUE = 1, > }t_bool; > > typedef struct > { > t_bool b0 : 1,... > }t_bitfield8; > It is undefined behavior prior to the C99 standard update and allowed as an implementation-defined extension in C99.What is the difference between these two cases.If the standard calls something "undefined" then the implementationis allowed to define it anyway. And if it is "allowed as an ID extension"but the extension is not provided, then it is UB. The difference is: If it is undefined but your compiler accepts it today, there is no guarantee what will happen tomorrow, if your compiler is updated, or if you change systems. If it is implementation defined, then every compliant compiler must document what it will do (or in this case if the extension is allowed). <> Nov 14 '05 #9