Hacker News Reader

Comment by isaachier | Hacker News Reader

Probably not a big deal assuming uint8_t is a typedef for unsigned char.

The problem is that this is an assumption, not a guarantee. If somewhere, somewhen, some toolchain decides "actually, let's define this to __u8 and do fancy stuff with this compiler-internal type", your code breaks in the most mysterious way possible.

Type uint8_t is guaranteed to have 8 bit, no padding bits, 2s complement. You are talking about uint_least8_t or int_fast8_t.

Quote:

Exact-width integer types

           The  typedef  name  intN_t  designates  a signed integer type with width N, no padding bits, and a two's-complement representation.
           Thus, int8_t denotes a signed integer type with a width of exactly 8 bits.

           The typedef name uintN_t designates an unsigned integer type with width N.  Thus, uint24_t denotes an unsigned integer type with  a
           width of exactly 24 bits.

But what about unsigned char? It is guaranteed to have CHAR_BIT bits, where CHAR_BIT is at least 8. If CHAR_BIT is greater than 8, then uint8_t cannot be typedef'd to unsigned char.

I've stopped programming in C if I can help it. It's a crazy language with support for crazy machines.

If CHAR_BITS is greater than 8, then uint8_t cannot be defined because CHAR_BITS is defined as the width of the smallest object that is not a bit-field. If uint8_t exists, it must be the same width as unsigned char.

It must have the same width as unsigned char in that scenario, but that does not make it unsigned char. § 6.5 of C11 only allows casting to "a character type" (and a few cases irrelevant in this context), not "a type of CHAR_BITS width". There's no requirement that uint8_t is a typedef for unsigned char.

Reply on news.ycombinator.com