Question

Is there any disadvantage to using char for small integers in C? Are there any advantages other than the occupancy/memory benefit?

In particular, is the processor likely to cope with integer arithmetic on a char better or worse than it would on a (long/short) int?

I know this will be processor/system/compiler specific, but I’m hoping for an answer in the general case, or, at least, the general case for 32-bit Windows and Solaris, being the systems I’m currently working on. I’m also assuming that things like overflow/wraparound issues have already been dealt with.

Update: Visual Studio 6.0 doesn’t actually have stdint.h as suggested by Christoph. A little benchmarking on Windows (VS 6.0, debug build, 32-bit) with a handful of stacked loops gives int and long as providing similar performance, which is about twice as fast as char. Running the same test on Linux with gcc similarly pegs int and long as similar, and both faster than char, although the difference is less pronounced.

As a side note, I’ve not spent much time looking, but the first implementation of stdint.h for VS 6.0 I found (via Wikipedia) defines uint_fast8_t as unsigned char, despite this seeming to be slower in my tests at least. Thus, the moral of the story, as Christoph rightly suggested: always benchmark!

Answer 1

C99 added so-called ‘fastest’ minimum-width integer types to solve this problem. For the range you’re interested in, the types would be int_fast8_t and uint_fast8_t, which can be found in stdint.h.

Keep in mind that there might be no performance gain (the increase in memory consumption might even slow things down); as always, benchmark! Don’t optimize prematurely or solely on potentially flawed assumptions of what should work.