How to change the MSB of an integer

Question

When I use the code below to change the 32 bit, or when bitc equals 31, it gives me -2147483643.

It seems to change all 0's to 1's instead of the last 0 only. How can I fix that in the code? Thanks in advance for the help.

#include <stdio.h>

int main()
{
  int num;
  int newnum;
  int orgnum;
  int bitc;
  int x;
  int check;
  printf("Enter the integer whose bits you want to manipulate. \n");
  scanf("%d",&num);
  orgnum=num;
  printf("What bit would you like to change? 0 is the rightmost bit and 31 is the leftmost bit. \n");
  scanf("%d",&bitc);
  printf("Type in 1 to turn on the bit or 0 to turn of the bit. \n");
  scanf("%d",&x);

  check= (num>>bitc)&1;

  if(x==1)
  {
    newnum=(num |= 1<<bitc);
  }
  else if(x==0)
  {

    if(check==0)
    {
      newnum=num;
    }

    else
    {
      newnum=(num &= ~(1<<x));
    }

  }

  printf("Your orignal number was: ");
  printf("%d", orgnum);
  printf("\n");
  printf("The new number after the bit manipulation is: ");
  printf("%d",newnum);


  //printf("%d //n|=1<<31;
  //printf("%d", n);
  //printf("%d", x);

  return 0;
}

Answer 1

Firstly, as has been mentioned already, when you wrote (1<<x) you meant to write (1<<bitc).

The main problem you are running into is that you are trying to use shifts on the sign bit. For an int, the most-significant-bit is called the sign bit because when set it means the number is negative.

Now, C runs on a wide range of systems and historically CPUs have implemented negative numbers differently. For this reason the C standard does not define operations that shift 1 in and out of the sign bit. So 1 << 31 causes undefined behaviour by shifting a 1 into the sign bit.

^{There are other issues that follow on from this, but to keep things brief I won't go into detail - all those issues are fixed by the following suggestion.}

---

To avoid these sign bit issues, the simplest and best option is to use unsigned types instead. Change all of your num values from int to unsigned int, and also change 1 << to 1U << in all cases. Then you can work on the most-significant-bit just like any other bit.

Also use %u instead of %d in scanf and printf when dealing with an unsigned int.

---

Regarding your code style:

Supposing we make this change to get newnum=(num |= 1U<<bitc);, it is still a bit convoluted. |= is compound assignment, so you are updating both num and newnum. But you only need to update one variable. In fact you have 2 redundant variables(orgnum and check) and some redundant tests.

Compare this with your original code:

if(x==1)
    newnum = num | (1U << bitc);
else
    newnum = num & ~(1U << bitc);

You don't have to pre-test for 0 in the unset case because it will set 0 anyway (the same reason you didn't pre-test for 1 in the set case).

Also it would be good to check that the user input is in range for unsigned int. If they type in a negative number or a number bigger than 31 for bitc you get undefined behaviour again.

What if you run your code on a system with 64-bit int, or 16-bit int? Basically you have two options here:

• use uint32_t instead of unsigned int, to guarantee 32-bit width (in this case check printf specifiers again as shown in David C Rankin's answer; and use (uint32_t)1 instead of 1U)
• keep using unsigned int and then use the expression CHAR_BIT * sizeof(int) - 1 instead of 31.

Answer 2

I think your line of code newnum=(num &= ~(1<<x)); is incorrect because you are using the value of x to shift the 1 bit to the position of the bit to change. That must be causing a problem. Shouldn't you be using bitc to shift the bit?

Also, you must be confused about the int data type in C. It's a signed integer with a two's complement representation. A binary number in two's complement with all of its bits set to 1, will equal decimal number -1, not decimal number -2147483643.

Hint: binary number 10000000000000000000000000000000 (32 bits), with a two's complement representation, is equal to the decimal number -2147483648.

Answer 3

When you begin manipulating bits, one of the biggest pitfalls people fall into is twiddling bits on signed data types. That is problematic due to several issues.

Take for example what occurs when you declare char c = 127;

c = 01111111;

and then do c += 1;. 128 cannot be represented by a signed char. If you look at the bits of c as a short, you see:

c = 1111111110000000; (-128 signed, 65408 unsigned)

If an unsigned type had been used for c, then sign extension does not apply. Moreover, bit operations on a signed type is implementation defined (same section of the standard), meaning how the conversion is handled is up to you, it is not specified by the C standard. So if you want well-defined behavior, limit bit manipulation to unsigned types.

(you are free to check the bits of signed types (e.g. to determine sign, even/odd, etc..), all of which are defined, but changing values of signed types by bit manipulation is implementation defined -- by you)

If you read the comments, using variables of exact width is important when you start fiddling with bits. stdint.h contains the exact width types (e.g. uint32_t guarantees a 32-bit unsigned value). inttypes.h provides macros you can use to read/print exact widths with scanf, printf, etc.., e.g.:

uint32_t bit;

printf ("Enter bit to change (0-31): ");
if (scanf ("%" SCNu32 "%*c", &bit) != 1 || bit > 31u) {
    fprintf (stderr, "error: invalid conversion or value for bit.\n");
    return 1;
}

Printing exacts widths works in similar manner:

printf ("bit : %" PRIu32 "\n", bit);

A very readable summary is Fixed width integer types (since C99).

The moral of the story is that you need to take a bit of care when manipulating bits, especially on signed types, because there are a number of pitfalls that await the unwary. There is absolutely nothing wrong with bit manipulations, there is a large body of efficient code out there that makes extensive use of them, but you have to make sure you avoid the subtle issues associated with them. (not to mention with modern processors, compilers, optimizations, gobs of memory, etc.. there are diminishing gains associated with them)

Hopefully this was helpful. Let me know if you have further questions.