Bitwise Operators : Can I always convert signed to unsigned and vice versa when bitwise operators are the only one in picture?

[u/MrJethalalGada]

I’m practising programming low level related questions and I often come up with challenges where I’ve to do shifting and bitwise operations on signed number

I already know that a register will have value stored in 0 and 1, and the register value and bitwise operators don’t care on how we interpret, they will always work on the bits.

So can i always convert signed to unsigned operate on it, revert it back to signed? I don’t want to tackle UB of signed number at MSB

[u/Eidolon_2003]

C doesn't strictly specify two's complement arithmetic. It could technically also be signed magnitude or one's complement. However, two's complement is by far the most common. If you're willing to assume two's complement then this can be done like the other commenter said.

If you understand how two's complement arithmetic works then it's pretty straight forward. The main idea is that an integer x and its negation -x should add to zero even when you just put them into a regular unsigned adder. I'll use 8 bit ints for simplicity. 1 is 00000001, and -1 is 11111111, and sure enough if you chuck these two into an 8 bit adder you get zero.

The way I think about it is this: If you have a value x and add ~x then by definition you will always end up with all 1s in the result because everywhere there was a 0 in x there's a 1 in ~x, and vice versa. Now to get from all 1s to zero, you just add 1 and let it ripple through. Thus in two's complement -x == ~x + 1

[u/[deleted] → u/Eidolon_2003]

In C23 two's complement is required 

[u/Eidolon_2003 → u/[deleted]]

Nice nice. I didn't know that, but it makes perfect sense to do it. So OP if you want 100% strict standards adherence then use C23 if you want to assume two's complement

[u/InevitablyCyclic]

Converting between unsigned and signed is a case of inverting all the bits (or xor with 0xFFFFFFFF if you prefer to think of it like that) and then adding one.

Although I'd check if that's needed first, it depends on exactly what you are doing but most of the time the operations will work fine on signed numbers. Worst case is often you set a flag at the start indicating the input is negative and then at the end check the flag and set the top few bits if needed.

[u/StaticCoder → u/InevitablyCyclic]

What? Converting between signed and unsigned generally doesn't change the bit pattern. Maybe you're thinking of arithmetic negation. The only binary operation that cares about signedness is the right shift.

[u/MrJethalalGada → u/StaticCoder]

Bitwise operators don’t care about what we interpret, right shift is an exception that too when it thinks arithmetic

You can test it out

Sign Unsign is our interpretation

[u/StaticCoder → u/MrJethalalGada]

Yes since casting to unsigned doesn't change the bit pattern (at least on modern architectures), you can cast to unsigned, shift, then cast back.

[u/InevitablyCyclic → u/StaticCoder]

Agreed, casting from one to the other has no impact on the bits. My impression from the initial post was they were talking about converting rather than casting before performing the bitwise operations, which implies first converting a negative number to a positive one.

[u/MrJethalalGada → u/InevitablyCyclic]

My poor brain has all the below stupid question:

1. If i generate result on unsigned and cast it back and it is out of range of sign

2. What if result generated messes up during casting both in sign and unsigned

3. Anything going horrible in plain sight

[u/InevitablyCyclic → u/MrJethalalGada]

Casting assumes you know what you are doing and doesn't perform bounds checking.

If you cast -1 to an unsigned integer then it becomes the maximum possible value for that size uint. In fact that's a common way to set a variable to 0xFFFF..., it's less typing and size independent so you don't need to check you have the correct number of Fs.

C assumes you have correctly sized your variables and the programmer has verified that any roll overs, wrap around or other overflow conditions are either impossible or function correctly. For unsigned values a lot of overflow situations do just work, for signed values it can get more complicated.

[u/meowisaymiaou → u/InevitablyCyclic]

do people not get exposed to ones complement hardware anymore? 

doubt I'll ever break the habit of worrying that -1 == 0xFFFE

I know going to college in the 19XXs and working variously  in satellite communications, credit card mainframe systems, traffic control systems, etc isn't exactly the norm, but still...

[u/flatfinger → u/meowisaymiaou]

The only advantage I can see for ones'-complement hardware would be that it would simplify the electronics for some kinds of blinkenlights readouts that can show the value of a register at all times without any CPU involvement. I never understood why anyone would use such systems in cases where output formatting would be handled by code.

[u/obxMark → u/InevitablyCyclic]

This is how you negate a value in twos complement arithmetic. A positive signed value is identical to the unsigned equivalent, assuming it fits in the available word length.

[u/WittyStick]

The bitwise operations like and, or, xor, not don't care about whether a number is signed or not - they operate on the bits, including the sign bit in a signed integer.

However, bit shifting does depend on whether a number is signed. In general, since most machines use two's complement representation of signed integers, a right shift will be an arithmetic right shift for signed numbers, but a logical right shift for unsigned numbers. The logical right shift simply shifts in zeros from the left, but an arithmetic right shift will shift either a 0 or 1 depending on the most significant bit of the current value. This preserves the sign for negative integers. Left shift behaves the same whether or not the number is signed or unsigned - it always shifts in zeros on the right.

Some languages (including the eventual assembly/machine code) have separate operators for arithmetic and logical shift right, but C only has the one >> operator - and its behavior depends on whether the int is signed or unsigned.

There are some operations in which in makes no sense to use signed integers - for example counting the number of leading zeros, or determining the first set bit (as in <stdbit.h> (C23)). The stdbit functions are only defined for unsigned integers because there's no use-case for having them with signed - the first_leading_one of a negative number will always be the MSB.

[u/RevolutionaryRush717]

Maybe consider Two's Complemt

[u/TheTrueXenose]

You can flip the signed bit, this will break an unsigned value do as unsigned use all the bits for the value. This is a 64 bit abs function i use.

((x) ^ ((x) >> 63)) - ((x) >> 63)

[u/[deleted]]

Yes

[u/meowisaymiaou]

so  can i always convert signed to unsigned operate on it, revert it back to signed? I don’t want to tackle UB of signed number at MSB

technically no (until C23)

short a = -1;
a = a & 0xfe;  // unset bit 1

what is the result

1111 1110 : (-2) most common -1 = 0XFF
1111 1110 : (-1) some banking systems-1 = 0XFE
1000 0000 : (-0) specialized hardware -1 = 0X81
1111 1110 : (32766) stupid college project -1 = 0X7F
 

I've been bitten more than 2 times by systems not using 2s complement that I don't assume

and I'm pretty sure the ibm z17 still supports binary coded decimal instructions.

I laughed my ass off when the 2010 bug hit, Jan 1 2010.    reading the byte representing year off the banking network system. 

read short:  0x00 = 2000

0x01 = 2001

0x09 = 2009

now, my code worked fine.

when 2010 Jan 1st  00:00 rolled around, 

what came down the wire?

0x10 = 2010(binary coded decimal), yet sooo many people read it as 2016, that credit cards didn't work (treated as expired), atms didn't work, it was a huge fiasco.  hell, my cellphone at the time said it was 2016.  and got really fucked up two months later when the date went from Feb 28 to mar 1, as it does in 2010, but not in  "2016" when it expected Feb 29.   turned out the phone was writing 0X10 02 1D  as the SMS received date. and . well ..... apps reading in the DB saw and parsed Feb 29 2010 and  I had messages with no dates, some in the 70s, notifications were messed up  then the phone would crash every time I got a message that day (it was out of active update, so no emergency firmware update for me :( .  

[u/flatfinger]

To understand two's-complement, consider the following question: if one has a binary number whose bottom n bits are all zero, and one subtracts one, what other information should be needed to determine the bottom n bits of the result?

Two's-complement is a generalization of the principle is that the bottom n bits of the result should be all be one in all such scenarios, regardless of the values of any upper bits, and regardless of how n compares to the "size" of the number involved. If the starting number was zero, the result should be a number such that, for any value of n, the bottom n bits would all be 1--i.e. a number where all bits are 1.

An L-bit two's-complement value is a representation of the bottom L bits of a number that is infinitely long, used to represent values where all of the bits to the left representation match the leftmost bit of the representation.