Tukukkk

I saw below code in this Quora post:

#include <stdio.h>



struct mystruct { int enabled:1; };

int main()

{

  struct mystruct s;

  s.enabled = 1;

  if(s.enabled == 1)

    printf("Is enabledn"); // --> we think this to be printed

  else

    printf("Is disabled !!n");

}

In both C & C++, the output of the code is unexpectedly,

Is disabled !!

Though the "sign bit" related explanation is given in that post, I am unable to understand, how is it possible that we set something and then it doesn't reflect as it is.

Can someone give more elaborate explanation?

Bit-fields are incredibly poorly defined by the standard. Given this code struct mystruct {int enabled:1;};, then we don't know:

• How much space this occupies - if there are padding bits/bytes and where they are located in memory.


• Where the bit is located in memory. Not defined and also depends on endianess.


• Whether an int:n bitfield is to be regarded as signed or unsigned.

Regarding the last part, C17 6.7.2.1/10 says:

A bit-field is interpreted as having a signed or unsigned integer type consisting of the
specified number of bits ¹²⁵⁾

Non-normative note explaining the above:

¹²⁵⁾ As specified in 6.7.2 above, if the actual type specifier used is int or a typedef-name defined as int,
then it is implementation-defined whether the bit-field is signed or unsigned.

In case the bitfield is to be regarded as signed int and you make a bit of size 1, then there is no room for data, only for the sign bit. This is the reason why your program might give weird results on some compilers.

Good practice:

• Never use bit-fields for any purpose.


• Avoid using signed int type for any form of bit manipulation.

I am unable to understand, how is it possible that we set something and then it doesn't show up as it is.

Are you asking why it compiles vs. gives you an error?

Yes, it should ideally give you an error. And it does, if you use your compiler's warnings. In GCC, with -Werror -Wall -pedantic:

main.cpp: In function 'int main()':

main.cpp:7:15: error: overflow in conversion from 'int' to 'signed char:1' 

changes value from '1' to '-1' [-Werror=overflow]

   s.enabled = 1;

           ^

The reasoning for why this is left up to being implementation-defined vs. an error may have more to do with historical usages, where requiring a cast would mean breaking old code. The authors of the standard may believe warnings were enough to pick up the slack for those concerned.

To throw in some prescriptivism, I'll echo @Lundin's statement: "Never use bit-fields for any purpose." If you have the kind of good reasons to get low-level and specific about your memory layout details that would get you to thinking you needed bitfields in the first place, the other associated requirements you almost certainly have will run up against their underspecification.

(TL;DR - If you're sophisticated enough to legitimately "need" bit-fields, they're not well-defined enough to serve you.)

This is implementation defined behavior. I am making the assumption that the machines you are running this on use twos-compliment signed integers and treat int in this case as a signed integer to explain why you don't enter if true part of the if statement.

struct mystruct { int enabled:1; };

declares enable as a 1 bit bit-field. Since it is signed, the valid values are -1 and 0. Setting the field to 1 overflows that bit going back to -1 (this is undefined behavior)

Essentially when dealing with a signed bit-field the max value is 2^(bits - 1) - 1 which is 0 in this case.

You could think of it as that in the 2's complement system, the left-most bit is the sign bit. Any signed integer with the left-most bit set is thus a negative value.

If you have a 1-bit signed integer, it has only the sign bit. So assigning 1 to that single bit can only set the sign bit. So, when reading it back, the value is interpreted as negative and so is -1.

The values a 1 bit signed integer can hold is -2^(n-1)= -2^(1-1)= -2^0= -1 and 2^n-1= 2^1-1=0