char has another use. I've always figured char pointers were the proper way to provide byte-level access to other objects, since char pointers are allowed to alias other pointer types. That is, they're not bound by strict aliasing rules. I don't think int8_t or uint8_t have the same special exception.

This means you could implement your own versions of memcpy, fread and fwrite by casting the void * arguments to char * , but if you cast them to uint8_t * , your code might not be correct.

That rule also applies to unsigned char and signed char. In practice I think uint8_t and int8_t are usually just typedefs for these respectively, but in principle they needn't be, so you're correct that the aliasing exemption might not apply to those.

I would tend to prefer explicitly using unsigned char or signed char rather than plain char though, partly to signal that I am treating the bytes as integers rather than character. (Actually I would still use uint8_t even though I just learnt it might not be unsigned char, because it looks clearer in my eyes, but I'm not sure I should admit it here...)

prior to C99 adoption char was usually how you got a int8_t. ascii characters are technically 7 bits, so should the extra bit be sign?

That's all just having fun, I like the consistency argument and the fact (is it a fact?) that char is signed on most platforms.

> char was usually how you got a int8_t

Not sure if that's just a typo, but you would use a signed char, which is a different type to char even on implementations where char is signed. Part of the reason for this, of course, is because char can be unsigned so if you want a signed integer you have to specify that. But more philosophically, unsigned char and signed char are numerical types that are not meant to be characters (despite their names), whereas char is a character type that just happens to be backed by an integer.

Indeed I believe that int8_t is almost always just a typedef for signed char (but I still would use int8_t where available for clarity).