In 2s complement, the most significant bit is the sign bit. In fact all valid C integer representations have a sign bit.

Signed integer representations. Unsigned ints do not, and you're given the full range of the integer as valid data.

Yes you're right. I should have been more specific that all signed integers have a sign bit.

This is wrong.

Take an integer value x. Flip the sign bit. Do you now have the value -x? On a 2s complement architecture, you do not. In 2s complement, you have to flip all the bits and add one to get -x.

Sign bit means one bit represents the sign of the integer which is the case with the most significant bit in 2s complement.

If you flip the sign bit, the sign changes. It does not mean that if you flip the sign, the value is negated.

I think his point is that changing a sign bit doesn't affect the absolute value, just its sign. A sign bit has no value itself - it's just a flag. If the representation has a sign bit, you'd have a negative zero.

But the top bit in 2s complement has a value - it's just a negative one (that's large enough to make any value with it set negative). That's not a sign bit! If you change it, the absolute value most definitely changes, and quite substantially.

This is a technicality. Leftmost bit still denotes a sign and modulo of the number is still capped at n-1 bits.

The differences between the representations matter. In 2s complement, -INT_MIN is not INT_MAX; in fact, -INT_MIN is undefined and a C compiler is justified in deleting all your code if you ever cause it to calculate -INT_MIN.

I tell you what: if you think modern architectures use an explicit sign bit to represent integers, how do you explain the fact that INT_MAX+1==-INT_MIN? If there's a sign bit, how could you possibly represent more negative integers than positive integers?

Are you arguing that given such, I have more than 63 bits for the number, or do you just have a problem with the usage of the words "sign flag"?