Signed and Unsigned

Started by
19 comments, last by MaulingMonkey 18 years, 10 months ago
unsigned int x;x = -1;printf("%u\n",x);printf("%i\n",x);

The results are 4294967295 and -1 respectively. The second one MAY issue a compiler warning if you have a savy enough compiler and are using the -Wall -W compile options.

Anyways, the point is in typing, because the two are nearly identical. I say nearly in that I'm not terribly sure if multiplication would yield the same results.
william bubel
Advertisement
Unsigned integers are stored in two's complement; they don't have a "signed" bit.
Quote:Original post by MaulingMonkey
Quote:Original post by Vampyre_Dark
signed -127 to +127


Nitpick: -128 to 127.
[lol] I couldn't remember last night which side got the extra digit, so I let it go.

Quote:Original post by Vampyre_Dark
Quote:Original post by MaulingMonkey
Quote:Original post by Vampyre_Dark
signed -127 to +127

Nitpick: -128 to 127.
[lol] I couldn't remember last night which side got the extra digit, so I let it go.

Nitpick: The range of a signed char type is SCHAR_MIN to SCHAR_MAX. The minimum range permitted by the standard is -127 to +127. So Vampyre_Dark's answer was the more accurate option.
Quote:Original post by bytecoder
Unsigned integers are stored in two's complement; they don't have a "signed" bit.

No, unsigned integers are stored in an unspecified format which may on some machines happen to be two's complement. The only requirement which the standard places upon the representation of unsigned integers is that for numbers which fit in the unsigned and signed variants of a particular integer type, the integers be the same. It is quite possible, and in fact does happen, for integers to have sign bits, be stored in one's complement or something even more exotic.

In addition, although char's sign is up to the compiler, char is neither signed char nor signed char. It is classed as a distinct type which just happens to have the same range as one of the other char types. This should mean that implicit conversions between plain chars and other chars should merit at least a warning. Microsoft Visual C++ doesn't bother issuing a warning for direct assignment, although it does correctly signal an error when assigning a pointer to a char type to a pointer to another char type.

[Edited by - Nathan Baum on May 28, 2005 4:33:09 PM]
Quote:Original post by Nathan Baum
Quote:Original post by Vampyre_Dark
Quote:Original post by MaulingMonkey
Quote:Original post by Vampyre_Dark
signed -127 to +127

Nitpick: -128 to 127.
[lol] I couldn't remember last night which side got the extra digit, so I let it go.

Nitpick: The range of a signed char type is SCHAR_MIN to SCHAR_MAX. The minimum range permitted by the standard is -127 to +127. So Vampyre_Dark's answer was the more accurate option.

Interesting, google says you're right too :-). There any x86 compilers that don't have an SCHAR_MIN of -128? (If not, it would seem the standard is -128, even if this isn't the "official" standard).

VD: I couldn't remember either, so I checked, hence why I actually posted proof [lol].
Quote:Original post by MaulingMonkey
There any x86 compilers that don't have an SCHAR_MIN of -128? (If not, it would seem the standard is -128, even if this isn't the "official" standard).

Assuming that x86 is, in some way, the standard CPU. And obviously assuming that chars are always 8 bits long.

Making assumptions about the architecture is usually a bad idea. Especially in games development, where it's actually fairly realistic to suppose you might at some point be developing for a non-x86 platform.
By that argument, -127 through 127 is just as wrong - we're making assumptions again. It could more easily be -2Mi through +2Mi-1.

I feel my point stands, -128 through 127 is extremely common, and I've never seen a system with -127 for SCHAR_MIN. Relying on SCHAR_MIN to be -127 for wrap-around purpouses would be an extremely bad idea because it will almost never happen. One could argue the same for -128, I won't disagree, but at least it'll work for SOME architectures.
Quote:Original post by MaulingMonkey
By that argument, -127 through 127 is just as wrong - we're making assumptions again. It could more easily be -2Mi through +2Mi-1.

No you're not. If the Standard says -127 to 127 is the minimum allowed range, then you aren't assuming anything. Its right there in the text, the miminum allowed range is -127 to 127. If it also says that the actual range is represented by SCHAR_MIN to SCHAR_MAX, then you again aren't assuming anything. The actual range is SCHAR_MIN to SCHAR_MAX.

I use numeric_limits<T> myself. Easier to remember.

CM
Quote:Original post by Conner McCloud
Quote:Original post by MaulingMonkey
By that argument, -127 through 127 is just as wrong - we're making assumptions again. It could more easily be -2Mi through +2Mi-1.

No you're not.


Let me be more explicit - You're not if you're explicitly not talking about the complete, full range of signed char. If you're talking about the complete, full range of a signed char, then it's an assumption.

When you talk about how fast a car can go, you don't say "My Ferrarri can go 10mph" when it can go 160mph (I'm no car expert, so deal with it if that number is off). You say "My Ferrarri can go 160mph", people are probably going to assume that's the maximum speed.

Similarly, one could say "signed char can cover the range [-3 .. +3]". Completely accurate - as long as you're not giving the impression that you can't store -4 or +4 as well.

I'm addressing the point where Nathan Baum states that Vampyre_Dark is somehow more accurate, when Vampyre_Dark made no mention of SCHAR_MIN, SCHAR_MAX, numeric_limits, etc, and left it completely unspecified if this was the full range, minimum standard full range, etc. Personally, when someone states a range like that, I take it to mean "this is the full range that ____ can cover". If I were Random N. Ewbie, heard about how overflow usually works, and assumed this, I'd think "So, if I try and assign 128 to a signed char, I'll get -127 right?" - which would be wrong.

I thought this was fairly obviously implied from my example assumption about overflows, but it apparently not.
Quote:Original post by MaulingMonkey
When you talk about how fast a car can go, you don't say "My Ferrarri can go 10mph" when it can go 160mph (I'm no car expert, so deal with it if that number is off). You say "My Ferrarri can go 160mph", people are probably going to assume that's the maximum speed.

There are any number of cases where you might say "my ferarri can go 10mph" even though it can also go at 160mph.

Let's assume that the minimum maximum speed of any car is 60mph. If somebody asks "what's the maximum speed of a car", which is more accurate: 60mph or 160mph? Obviously the most accurate response wouldn't be either of them, but I think there's a clear conceptual difference between giving an answer which is within the speed ranges of all cars and giving one that is out of the range of some. I think the answer 60mph would somehow be more accurate, because all cars can at least achieve that speed.
Quote:
I'm addressing the point where Nathan Baum states that Vampyre_Dark is somehow more accurate, when Vampyre_Dark made no mention of SCHAR_MIN, SCHAR_MAX, numeric_limits, etc, and left it completely unspecified if this was the full range, minimum standard full range, etc.

You said signed chars have the range -128 to 127. According to the standard, that is a false statement to make. They don't necessarily support all values in that range.

He said signed chars have the range -127 to 127. According to the standard, that is a true statement to make. They necessarily support all values in that range.

Vampyre_Dark obviously meant the full range, so he was wrong. But, if one wrote well-formed programs on the basis that the full range of signed chars was -127 to 127, they would be guaranteed to work on all compliant implementaions. Whilst assuming a range of -128 to 127 wouldn't have the same guarantee.

The range of a signed char is either [ -127, 127 ] or [ SCHAR_MIN, SCHAR_MAX ]. No other statement of the range of a signed char is accurate without qualification of which implementation you are referring to.
Quote:
Personally, when someone states a range like that, I take it to mean "this is the full range that ____ can cover". If I were Random N. Ewbie, heard about how overflow usually works, and assumed this, I'd think "So, if I try and assign 128 to a signed char, I'll get -127 right?" - which would be wrong.

If you knew about how overflow worked according to the standard, you'd know that the behaviour of a signed type upon receiving a value that is out of range is undefined. The question of whether or not there is bounds checking on signed integer types is left up to the implementation to decide.

This is the whole problem with C/C++ portability. Students are taught that "all the world's an IBM compatible". Instead of being told that the range of a signed char is at least -127 to 127, and more precisely SCHAR_MIN to SCHAR_MAX, they are told it's -128 to 127 and may potentially have to unlearn that if they do some programming for an unusual architecture.

This topic is closed to new replies.

Advertisement