Open AlexMax opened 1 month ago
An alignCast sounds wrong here, because p
absolutely has no guarantee to be 8 byte aligned. The more correct solution would be cast to a *align(1) u64
, but im not sure translate-c has the information required to know that.
Using @alignCast
would be technically correct, since standard C simply makes creating underaligned pointers UB.
ISO/IEC 9899:1999 § 6.3.2.3(7):
A pointer to an object or an incomplete type may be converted to a pointer to a different object or incomplete type. If the resulting pointer is not correctly aligned for pointed-to type, the behavior is undefined.
It's probably more useful to add an align
annotation. I'm not certain about how possible this is, and whether we'd be able to omit it in common cases (where the alignment requirement of the new pointee is trivially no greater than that of the old pointee).
Zig Version
0.14.0-dev.909+f9f894200
Steps to Reproduce and Observed Behavior
I ran this C code (from SMhasher) through
zig translate-c
:This results in the following Zig function - trimming the bits outside the function:
Trying to compile this function as zig code gives me an error:
This seems like an accurate report - however since the original code seemingly doesn't care about alignment concerns, I would think that
translate-c
would add an alignment cast to the translated code.Expected Behavior
translate-c
should add an alignment cast in the spot pointed out by the error, and the function should compile successfully.