A typedef to a character type is a character type. See <a href="http:&#x2F;&#x2F;port70.net&#x2F;~nsz&#x2F;c&#x2F;c11&#x2F;n1570.html#6.7.8p3" rel="nofollow">http:&#x2F;&#x2F;port70.net&#x2F;~nsz&#x2F;c&#x2F;c11&#x2F;n1570.html#6.7.8p3</a>.<p><a href="http:&#x2F;&#x2F;port70.net&#x2F;~nsz&#x2F;c&#x2F;c11&#x2F;n1570.html#6.2.5p4" rel="nofollow">http:&#x2F;&#x2F;port70.net&#x2F;~nsz&#x2F;c&#x2F;c11&#x2F;n1570.html#6.2.5p4</a> leaves open the option for extended signed integer types, and the following paragraph provides for an unsigned integer type for each signed type, extended signed types included.<p>So it would be perfectly possible, if not actually very reasonable - not that this is stopping anybody at the moment - for an implementation to provide __int8, a signed 8-bit integer type that fulfils all the requirements of uint8_t, but is not a character type, and use that as uint8_t. Then, conceivably, it could fail to support the use of uint8_t pointers to alias other objects, something supported by the more usual situation of using unsigned char for uint8_t.<p>I&#x27;m not sure that anybody would do this, but they could. I&#x27;m rather surprised gcc doesn&#x27;t do it, come to think of it, just to teach its users a lesson. Maybe I should file a bug report?