Zig Version
0.11.0-dev.1333+d56a65a8c
Steps to Reproduce and Observed Behavior
Consider the following library source (simple one liner is not enough)
// gurka.zigexportfndoit(data: [*]u8, len: usize) callconv(.C) isize {
varsum: isize=0;
varipos: usize=0;
while (ipos<len) {
constbyte: isize=data[ipos];
consttoken: isize=byte-48;
if (token<0ortoken>9) break;
sum=sum+token;
ipos+=1;
}
returnsum;
}The following sequence of commands break:
zig build-lib gurka.zig
zig build-lib gurka.zig -fno-LLVM
output:
Program aborted due to an unhandled Error:
st_name (0x48000000) is past the end of the string table of size 0xfe
[1] 45564 IOT instruction (core dumped) zig build-lib gurka.zig -fno-LLVM
however, the following variant works fine
zig build-lib gurka.zig
rm libgurka.*
zig build-lib gurka.zig -fno-LLVM
(as well as only running the very last command in an otherwise empty dir)
Expected Behavior
No compile-time crash. no dependence on stale outputs from a previous zig build-exe with different compiler flags.
(yes, the actual compiler output of native assembly itself might be incorrect. I fully expect this, as I intend to work on this part myself. I report this as a stumbling block to even sanely compare the output of different code-gen backends)
Zig Version
0.11.0-dev.1333+d56a65a8c
Steps to Reproduce and Observed Behavior
Consider the following library source (simple one liner is not enough)
The following sequence of commands break:
output:
however, the following variant works fine
(as well as only running the very last command in an otherwise empty dir)
Expected Behavior
No compile-time crash. no dependence on stale outputs from a previous
zig build-exewith different compiler flags.(yes, the actual compiler output of native assembly itself might be incorrect. I fully expect this, as I intend to work on this part myself. I report this as a stumbling block to even sanely compare the output of different code-gen backends)