Per VognsenFeb 23
Saw this when randomly flipping through the code base of something posted to Lobsters. C or C++ is not the language for you if you think you can write code like that. https://c.godbolt.org/z/8q5zoh6Ke
Compiler Explorer - C (x86-64 gcc 15.2)

// https://github.com/abdimoallim/jit typedef int32_t i32; typedef uint8_t u8; typedef size_t usz; typedef struct { u8* buf; usz len; } jit_buf; void jit_ensure(jit_buf* j, usz n) {} // bad void jit_emit_i32(jit_buf* j, i32 v) { jit_ensure(j, 4); j->buf[j->len + 0] = (u8)(v); j->buf[j->len + 1] = (u8)(v >> 8); j->buf[j->len + 2] = (u8)(v >> 16); j->buf[j->len + 3] = (u8)(v >> 24); j->len += 4; } // good void jit_emit_i32_fixed(jit_buf* j, i32 v) { jit_ensure(j, 4); u8* buf = j->buf; usz len = j->len; buf[len + 0] = (u8)(v); buf[len + 1] = (u8)(v >> 8); buf[len + 2] = (u8)(v >> 16); buf[len + 3] = (u8)(v >> 24); j->len = len + 4; } int main() {}

Show threadNicolai Hähnle

@pervognsen Generally agree, but the buf pointee is uint8_t, so technically shouldn't strict aliasing apply here and guarantee that buf cannot alias j->len?

That said, this whole situation is clearly a mess in C++ and clearly much better in Rust.

Feb 23 at 4:56amWeb
Show threadPer VognsenFeb 23
@nh I'm not trying to promote anything else, I'm just saying _if_ you want to write code like that then C or C++ isn't the right language, i.e. you need to be explicit about loads and stores and understand when they're happening (especially bad with C++ member variables).
Show threadPer VognsenFeb 23
@nh Regarding uint8_t I don't know what the standard says but I've never seen a compiler that doesn't optimize uint8_t and friends the same way as char when it comes to the special type-based aliasing rules for char pointer reads/writes.
Show threadBas NieuwenhuizenFeb 23
@nh @pervognsen iirc char can alias with anything and depending on the platform uint8_t may be char, so this potentially still aliases on some platforms?
Show threadAlexander MonakovFeb 23

@bas @nh @pervognsen realistically uint8_t can't be anything but unsigned char in C on modern platforms, no?

even attempting to side-step the issue with
typedef int i8 __attribute__((mode(QI)))
won't help, the resulting type still aliases like char in both Clang and GCC

(however, in C++20 char8_t is a distinct type and does not alias everything)