C - is any use of unsigned int just terrible coding practice?

Question

Are there any examples of legitimately good use of an unsigned data (i.e. unsigned int) or should use of unsigned data types just be considered very bad coding practice as a relic of resource impaired platforms from the 1970s and 1980s?

Consider this:

int main ()
{
    unsigned int a = 5;   /*or uint32_t if you prefer*/
    unsigned int b = 8
    unsigned int c = a - b; // I can't even store a subtraction result
                            // from my own data type!

    float f;    // ISO didn't even bother to make a signed version of float.
    double d;   // ISO didn't even bother to make a signed version of double.

    // size_t is an unsigned integer, length varies
    // (4 bytes on 32 bit platforms typically, 8 on 64 bit, ...)
    size_t size1 = 100; 
    size_t size2 = 200;

    // What's a ssize_t -- it's a signed size_t because size_t can't store subtractions.
    // So ssize_t is an bad idea to correct for the bad idea of a size_t being unsigned
    ssize_t size3 = size1 - size3;

    // unsigned operations don't overflow/underflow
    size_t  size4 = size1 - size3; // I don't even underflow, I just wrap.
                                    // Which means unsigned isn't even good
                                    // For use as a pseudo data "validation"
}

Additionally, the C definition of memset, as an example:

void * memset ( void * ptr, int value, size_t num );

memset's value argument is really an unsigned char, but a great number of functions convert unsigned char to int simply to dodge use of an unsigned data type or how printf promotes char to int.

And in a scenario where unsigned is being used for the slightly greater range (i.e. 32-bit 4GB) that is more a sign that the wrong datatype is being used and that either a int64 variant or a double should actually be used to store the value to begin with.

There has to be some legitimate use of unsigned but I can't think of a scenario. So what scenario should unsigned types be used?

Answer 1

The rule of the thumb in this case is very simple: use unsigned types to represent unsigned values, use signed type to represent signed values. So, in reality it is just the opposite: most of the time gratuitous use of signed types is a terrible coding practice. I'd even go as far as to say that most of integer types in the code are supposed to be unsigned. Of course, the actual ratio will depend on the application area, but for combinatorial problems and related domains: it is unsigned, unsigned and only unsigned.

Your above example with wrap-around behavior simply demonstrates typical newbie coding error. And in its essence it is no different from the popular

double d = 1/2;

followed by something like "why my d is not 0.5?".

Note also that in the domain of integral calculations unsigned types are typically more efficient than signed ones (C rounding rules for division are different from the typical machine-supported ones and make a negative impact on the performance of signed types). In mixed integer-floating point calculations signed integer types might have an edge (FPU instruction set typically supports signed integers directly, but not unsigned ones).

great number of functions convert unsigned char to int simply to dodge use of an unsigned data type

Nope. Conversion to int is a rudiment of that bygone era when C language had no function prototypes. All functions were declared without prototypes (or left undeclared), which triggered automatic promotions of smaller integer arguments to int. Once prototypes for standard functions appeared, there were intentionally tailored to be compatible with legacy behavior. For this reason you will never see a "classic" standard library function that accepts [signed/unsigned] char, [signed/unsigned] short arguments (or float for that matter). Signedness has nothing to do with it.

Answer 2

All types clarify and enforce purpose, and thus these are useful too. Unsigned is good programming practice to indicate the intention, to yourself and others, of use of the data element - just in the same way all types are used.

For example, a normal array index variable should never be negative and so declaring the variable unsigned should be best practice. Another usage is common in the lower sized elements of "short int" and "int", at the very least, where one may find use doubling the maximum value store-able by going unsigned (gaining another bit in the positive numbering space), rather than doubling the amount of space used. This is true despite more available storage space for "modern guys", considering one might store lots of these items, for example in a large array. Efficient/careful coding should not be relegated to the last century just because of resource enhancements.

I'd venture that abnormal lack of usage is more likely careless coding, rather than obsolescence. As for ISO standard indicating obsolescence, the ISO specs I find they specify unsigned for all integer types: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf, in section 6.2.5 "There are five standard signed integer types, designated as signed char, short int, int, long int, and long long int" and then goes on to say "For each of the signed integer types, there is a corresponding (but different) unsigned integer type". As for floats, which are quite a different type, the argument is made at Why no unsigned floating point types? that at 32+ bits, and with normal usage, the feature was probably not found useful enough - and its always been that way, not related to changes over time.

Answer 3

Resource restricted platforms still exist, e.g. 8-bit microcontrollers.

unsigned char i;
for (i = 0; i < 131; i++) {
    /* use i */
}

When the CPU directly supports only 8-bit operations but your loop limit is 131, you can use the 8-bit unsigned type and have your code is still efficient (i.e. not using software emulated 16-bit operations).

---

Update about integer promotion: Compilers are fortunately smart enough to avoid producing unnecessary code. The example above compiles to a code that really works only with 8-bit values on such 8-bit microcontrollers.