title: Pros/cons to using char for small integers in C
body: <p>Is there any disadvantage to using <code>char</code> for small integers in C? Are there any advantages other than the occupancy/memory benefit?</p>
  
  <p>In particular, is the processor likely to cope with integer arithmetic on a <code>char</code> better or worse than it would on a (<code>long</code>/<code>short</code>) <code>int</code>?</p>
  
  <p>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.</p>
  
  <p>Update: Visual Studio 6.0 doesn't actually have <code>stdint.h</code> as suggested by Christoph. A little benchmarking on Windows (VS 6.0, debug build, 32-bit) with a handful of stacked loops gives <code>int</code> and <code>long</code> as providing similar performance, which is about twice as fast as <code>char</code>. Running the same test on Linux with gcc similarly pegs <code>int</code> and <code>long</code> as similar, and both faster than <code>char</code>, although the difference is less pronounced.</p>
  
  <p>As a side note, I've not spent much time looking, but <a href="http://msinttypes.googlecode.com/svn/trunk/stdint.h" rel="nofollow noreferrer" title="Visual Studio implementation of stdint.h">the first implementation of <code>stdint.h</code> for VS 6.0 I found</a> (via <a href="http://en.wikipedia.org/w/index.php?title=Stdint.h&amp;oldid=335927920" rel="nofollow noreferrer" title="stdint.h on Wikipedia">Wikipedia</a>) defines <code>uint_fast8_t</code> as <code>unsigned char</code>, despite this seeming to be slower in my tests at least. Thus, the moral of the story, as Christoph rightly suggested: always benchmark!</p>