3 ms·

Bonus mess: If hash_function operates on bytes, but the input is cast to uint8_t* instead of (unsigned) char*, this is also a violation of aliasing rules and th

Bonus mess: If hash_function operates on bytes, but the input is cast to uint8_t* instead of (unsigned) char*, this is also a violation of aliasing rules and the compiler can technically just do whatever.

isaachier 8y ago
Probably not a big deal assuming uint8_t is a typedef for unsigned char.
- beefhash 8y ago
  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.
  - v_lisivka 8y ago
    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.
    - Mindless2112 8y ago
      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.
      - TheCoelacanth 8y ago
        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.
        beefhash 8y ago
        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.
im3w1l 8y ago
But uint8_t will most of the time be typedefed to unsigned char in stdint.h. So your code should be fine right now but may or may not become undefined in the future
xroche 8y ago
Hummm, are you sure ? C Standard seems to allow signed/unsigned variants for aliasing rules ("a type that is the signed or unsigned type corresponding to the effective type of the object, a type that is the signed or unsigned type corresponding to a qualified version of the effective type of the object")

isaachier 8y ago

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

beefhash 8y ago
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.
- v_lisivka 8y ago
  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.
  - Mindless2112 8y ago
    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.
    - TheCoelacanth 8y ago
      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.
      - beefhash 8y ago
        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.

im3w1l 8y ago

But uint8_t will most of the time be typedefed to unsigned char in stdint.h. So your code should be fine right now but may or may not become undefined in the future

xroche 8y ago

Hummm, are you sure ? C Standard seems to allow signed/unsigned variants for aliasing rules ("a type that is the signed or unsigned type corresponding to the effective type of the object, a type that is the signed or unsigned type corresponding to a qualified version of the effective type of the object")