Bitwise-or seems to have an implicit cast to long. Can this be avoided?

Question

I'm a Java programmer trying to migrate to C#, and this gotcha has me slightly stumped:

int a = 1;

a = 0x08000000 | a;
a = 0x80000000 | a;

The first line compiles just fine. The second does not. It seems to recognise that there is a constant with a sign bit, and for some reason it decides to cast the result to a long, resulting in the error:

Cannot implicitly convert type 'long' to 'int'.
An explicit conversion exists (are you missing a cast?)

The fix I have so far is:

a = (int)(0x80000000 | a);

Which deals with the cast but still leaves a warning:

Bitwise-or operator used on a sign-extended operand;
consider casting to a smaller unsigned type first

What would be the correct C# way to express this in an error/warning/long-free way?

Answer 1

Your issue is because 0x80000000 is a minus in int form and you cannot perform bitwise operations on minus values.

It should work fine if you use a uint.

a = ((uint)0x80000000) | a;  //assuming a is a uint

Answer 2

I think

a = (unsigned int)(0x80000000) | a;

should work. This is failing, as Nanook states, because 0x80000000 as an int is negative, and you can't perform bitwise operations on a negative signed integer. If you explicitly cast it to uint first, it should work.

Answer 3

Changing that line to
(int)((uint)0x80000000 | (uint)a);
does it for me.

Answer 4

A numeric integer literal is an int by default, unless the number is too large to fit in an int and it becomes an uint instead (and so on for long and ulong).

As the value 0x80000000 is too large to fit in an int, it's an uint value. When you use the | operator on an int and an uint both are extended to long as neither can be safely converted to the other.

The value can be represented as an int, but then you have to ignore that it becomes a negative value. The compiler won't do that silently, so you have to instruct it to make the value an int without caring about the overflow:

a = unchecked((int)0x80000000) | a;

(Note: This only instructs the compiler how to convert the value, so there is no code created for doing the conversion to int.)

Answer 5

The problem you have here is that

• 0x80000000 is an unsigned integer literal. The specification says that an integer literal is of the first type in the list (int, uint, long, ulong) which can hold the literal. In this case it is uint.
• a is probably an int

This causes the result to be a long. I don't see a nicer way other than cast the result back to int, unless you know that a can't be negative. Then you can cast a to uint or declare it that way in the first place.

Answer 6

I find it interesting that in all these answers, only one person actually suggested doing what the warning says. The warning is telling you how to fix the problem; pay attention to it.

Bitwise-or operator used on a sign-extended operand; consider casting to a smaller unsigned type first

The bitwise or operator is being used on a sign-extended operand: the int. That's causing the result to be converted to a larger type: long. An unsigned type smaller than long is uint. So do what the warning says; cast the sign-extended operand -- the int -- to uint:

result = (int)(0x80000000 | (uint) operand);

Now there is no sign extension.

Of course this just raises the larger question: why are you treating a signed integer as a bitfield in the first place? This seems like a dangerous thing to do.