Pitfalls in C and C++: Unsigned Types (2011)

  > “Unsigned has a bigger range.”
  > Only a bit bigger.

I'm not particularly fond of the trend toward avoiding unsigned integers (in particular the lack of unsigned types in Java and array lengths being signed in C#).

A good programmer should be capable of determining whether to use a signed or unsigned type; if it's not easy to decide, that indicates a design flaw to me.

If you program C like there's no overflow, it doesn't matter much whether you mis-index the next array with 4294967295 or -1. There's no substitute for overflow-vigilance, and particularly not rules like "such-and-such type is bad and such-and-such type is better".

(BTW: an ex-boss of mine claimed that signed ints were evil because because and insisted on using unsigned for everything, but that's a different story, and I'm glad he's an ex-boss)

I think most languages would benefit from unsigned types being the default, and arithmetic overflow being a hard error unless otherwise decorated. Signedness and lenient overflow promote laziness. Array indexes don't make sense as signed, yet most people prefer to iterate arrays with a signed type, e.g most commonly:

  for (int i = 0; i < 10; ++i) buf[i] = 0;

There are countless security issues I've had to fix related to signed types in what is supposed to be secure code. These would not have occurred if the author was forced to use an unsigned type, and had to consider the extreme limits of the values it can take on. Subtle things such as the addressable limit of memory being naturally unsigned, but buffer sizes being passed as signed, can cause easy exploits, and are stupidly commonplace.

Compare this to, say, the "declarations-as-assertions" extension in CMUCL/SBCL: when you declare an unsigned type, underflow conditions will be reported:

  * (defun test (x) 
	(the (integer 0) (1- x))
	)
  * (test 0)

  debugger invoked on a TYPE-ERROR in thread
  #<THREAD "main thread" RUNNING {1002B2AF23}>:
    The value -1 is not of type UNSIGNED-BYTE.

    #include <iostream>

    int main()
    {
        unsigned I;

        // 0 to 4, for loop
        for (I = 0; I != 5; ++I) std::cout << I << "\n";
        std::cout << "\n";

        // 4 to 0, for loop
        for (I = 5; I-- != 0;) std::cout << I << "\n";
        std::cout << "\n";

        // 0 to 4, while loop
        I = 0;
        while (I != 5)
        {
            std::cout << I << "\n";
            ++I;
        }
        std::cout << "\n";

        // 4 to 0, while loop
        I = 5;
        while (I != 0)
        {
            --I;
            std::cout << I << "\n";
        }
        std::cout << "\n";
    }

  for (ptrdiff_t i = 0; i != ptrdiff_t(v.size()); ++i)

In many other cases, one of the common bugs is unexpected sign extension when a type is promoted to a larger one -- the most common being extension of a signed character to an integer, which can result in some wildly negative values.

Those who have been hit by that frequently will prefer unsigned types.

As with most things, your mileage may vary.

-dB

First, arr[(unsigned)-1] will segfault while arr[-1] will likely cause harder to debug non-local problems.

Second, mod in C and C++ is broken(ish) on signed values: negative % positive returns a negative number. This means in order to use it as an index you need to check the value and add the table size post-mod if you want to wrap an index into an array (as you might for a hash table or ring buffer).