I think it isn't clear what the standard means here. If uint8_t exists it must be a typedef to unsigned char (edit: unless to3m is right that there could be a distinct 8-bit implementation-defined integer type, which I didn't think was allowed but maybe it is), so the question is if a typedef to a character type is a character type. My reading is that it isn't, but I've heard enough good C programmers assume that it is that either I am wrong or hopefully compilers will always allow uint8_t to work in this case. It certainly makes more sense to use uint8_t than unsigned char for that usage, but ideally maybe there would be a standard byte_alias_t or such.
http://port70.net/~nsz/c/c11/n1570.html#6.2.5p4 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.
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.
I'm not sure that anybody would do this, but they could. I'm rather surprised gcc doesn't do it, come to think of it, just to teach its users a lesson. Maybe I should file a bug report?
Thanks, good to know the full situation. I'll try to remember not to use uint8_t that way in the future, just in case.
I looked briefly previously and somehow got the sense that extended types could only be larger than standard types, but this time I found that 6.3.1.1 explicitly mentions same width extended types.
Personally, I've been happy with GCC's decisions on such issues.
