Open Yeaseen opened 11 hours ago
I don't see the issue in the generated code, rather something in the type check / access pattern of b.*[n] = x
might be wrong in the compiler:
@TypeOf(b.*[0]) == @TypeOf(b.*[1]) == c_int
(imo correct)@TypeOf(&(b.*[1])) == *[2]c_int
(imo wrong)
It seems like taking the address of the double-dereference [*c]
-Pointer access somehow moves us up two layers / to the root?
If myarray
is declared as *[2]c_int
, the issue doesn't happen.@TypeOf(&(b.*[0])) == *allowzero [2]c_int
, which I also can't explain - maybe we're incorrectly reinterpreting (uninitialized?) memory in some way?
This also doesn't happen for myarray = *[2]c_int
.
Zig Version
0.14.0-dev.2064+b5cafe223
Steps to Reproduce and Observed Behavior
Input C Code
Translated zig code
zig build failure
The generated zig code incorrectly uses a cast that results in a
comptime_int
type mismatch, making it impossible to modify the array elements as intended.Expected Behavior
The
zig translate-c
tool should generate the correct zig code that allows accessing and modifying array elements through a pointer. For example, the output zig code should correctly handle the array pointer and allow the assignment.