You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Additional information:
If I change const i: c_int = 5 to var i: c_int = 5 it will set i to 12345.
Expected Behavior
I expect a compilation error like expected type '*c_int', found '*const c_int' or something similar. Or if this compiled successfully I would expect it to set i to 12345. Either way, I think the current behavior is a bug
The text was updated successfully, but these errors were encountered:
that compile error isnt possible unless the language was changed to always require passing mutable pointers to varargs which would be silly. im guessing that here the compiler inlines the 5 since it sees that its (theoretically) impossible for it to change, maybe you could argue that behavior shouldnt happen but i think its fairly reasonable. even clang does the same thing when it has a full view of what happens in the code
that compile error isnt possible unless the language was changed to always require passing mutable pointers to varargs which would be silly
While it may sound silly, I actually think it would properly fix this misbehavior.
Say we introduced that requirement, all that changes is that the caller has to wrap the pointer-to-const arguments with @constCast, which clearly signals to be wary when doing this.
It's pretty much exactly the scenario for when/why @constCast already exists in status-quo.
To me this solution seems like a solid improvement over sticking with status-quo.
Zig Version
0.13.0-dev.46+3648d7df1
Steps to Reproduce and Observed Behavior
reproed on linux aarch64
with these files
run
zig run main.zig lib.a
Received output:
Additional information:
If I change
const i: c_int = 5
tovar i: c_int = 5
it will seti
to 12345.Expected Behavior
I expect a compilation error like
expected type '*c_int', found '*const c_int'
or something similar. Or if this compiled successfully I would expect it to seti
to 12345. Either way, I think the current behavior is a bugThe text was updated successfully, but these errors were encountered: