Post History

Yes, it is in practice always a character type and you can safely assume as much, both in terms of (g)lvalue access and in terms of strict pointer aliasing. If not, the compiler would soon render itself completely useless. 

C and C++ both got the following rule (C17 7.20.1.1/3)

> `intN_t` ... `uintN_t` ...
> 
> These types  are optional. However, if an implementation provides integer types with
widths of 8, 16, 32, or 64 bits, no padding bits, and (for the signed types) that have a
two’s complement representation, it shall define the corresponding typedef names.

So if your system supports 8 bit 2's complement numbers, it must support `uint8_t`. No exceptions - not even for freestanding (embedded) systems - `stdint.h` is one of the mandatory headers for all conforming implementations (C17 4/6).

And for such a system it does not make sense to define `unsigned char` as anything else but 8 bits. `CHAR_BITS` will be 8. 

Padding bits, trap representations and other such exotic oddities is not allowed for character types either, nor can trap representations exist in 2's complement integers.

In practice, all known real-world compilers will simply implement `uint8_t` as a `typedef` for `unsigned char`. You can easily prove this by trial and error:

---

C

    _Generic((uint8_t){0}, uint8_t:0, unsigned char:0);

> error: '_Generic' specifies two compatible types

---

C++

    void f (unsigned char c){}
    void f (uint8_t c){}

> error: redefinition of `void f(uint8_t)`  
> note: `void f(unsigned char)` previously defined here
 `void f (unsigned char c){}`

---

For those few exotic systems that have 16 bit bytes or other oddities like 1's complement, they cannot support `uint8_t` in the first place.