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
Below is a selection of slice operations showing the variety of outcome when slicing pointers which are known to be undefined at compile time.
varend: usize=1;
pubfnmain() void {
// 1. OK_=@as([*]u8, undefined)[0..0];
// 2. OK_=@as(*[0]u8, undefined)[0..0];
_=@as(*u8, undefined)[0..0];
varx: u8=47;
// 3. OK_=@as([*]u8, undefined)[0..end];
_=@as([*]u8, undefined)[0..end :1];
_=@as([*]u8, undefined)[0..@intFromPtr(&x) :47];
// 4. Runtime panic: index out of bounds: index 2, len 0_=@as(*[0]u8, undefined)[0..end :0];
// 5. Compile error: start index 1 is larger than end index 0_=@as(*[0:1]u8, undefined)[1..];
// 6. Compile error: non-zero length slice of undefined pointer_=@as([*]u8, undefined)[0..1];
// 7. Compile error: slice of undefined_=@as([]u8, undefined)[0..0];
// 8. Compile error: use of undefined value here causes undefined behavior_=@as([]u8, undefined)[0..end];
_=@as([*c]u8, undefined)[0..0];
// 9. Compile error: end index 1 out of bounds for slice of length 0_=@as([]u8, &.{})[0..1];
// 10. Runtime panic: index out of bounds: index 1, len 0_=@as([]u8, &.{})[0..end];
}
There are at least two behaviours for slicing compile-time-known undefined pointers. Slice pointer operands outright prevent it, while Many and One pointer operands require that the result length is equal to 0.
For other inputs the control flow reaches errors in other functions (case 8) before Sema.analyzeSlice can determine the outcome, or the compiler can not discern that the input is effectively undefined (cases 9 and 10).
The inconsistency is not a bug, but it is also not good. Every slice operation where the pointer operand is known to be undefined at compile time should produce the same outcome. However this might currently be impossible for cases 9 and 10.
Case 3 is the bug, because the same syntax (with the same pointer operand type) produces a compile error if the length of the result is known to be non-zero at compile time. This requirement has no runtime equivalent.
The addition of a sentinel to this (case 3, expression 1) variant compiles an unavoidable runtime memory error, as the sentinel safety check will attempt to dereference the compile-time-known undefined pointer, offset by the runtime-known end operand (sentinel index).
How is tmp undefined?
Compile and run with zig run undefined_slice_ptr_tuple_lit.zig undefined_slice_ptr_tuple_lit.zig:
zig run undefined_slice_ptr_tuple_lit.zig
aaaaaaaaaaaaaaab
Something is going on here, because the integer value of tmp.ptr at runtime shows the sum of undefined and 1, an operation that completed at compile time and produced a compile-time-known pointer (as shown by the tuple type). Maybe another issue?
Expected Behaviour
Cases 1 to 8 inclusive should have the same behaviour. Here are some options:
Always a compile error: an undefined pointer is 'garbage in', and the slice syntax should not allow 'garbage out'.
Length must be zero; checked at both compile time and runtime.
Length must be zero; checked at compile time, or a compile error if a runtime length makes checking impossible.
The text was updated successfully, but these errors were encountered:
Zig Version
0.13.0-dev.46+3648d7df1
Behaviour
Below is a selection of slice operations showing the variety of outcome when slicing pointers which are known to be undefined at compile time.
There are at least two behaviours for slicing compile-time-known undefined pointers.
Slice
pointer operands outright prevent it, whileMany
andOne
pointer operands require that the result length is equal to 0.For other inputs the control flow reaches errors in other functions (case 8) before
Sema.analyzeSlice
can determine the outcome, or the compiler can not discern that the input is effectively undefined (cases 9 and 10).The inconsistency is not a bug, but it is also not good. Every slice operation where the pointer operand is known to be undefined at compile time should produce the same outcome. However this might currently be impossible for cases 9 and 10.
Case 3 is the bug, because the same syntax (with the same pointer operand type) produces a compile error if the length of the result is known to be non-zero at compile time. This requirement has no runtime equivalent.
The addition of a sentinel to this (case 3, expression 1) variant compiles an unavoidable runtime memory error, as the sentinel safety check will attempt to dereference the compile-time-known undefined pointer, offset by the runtime-known end operand (sentinel index).
How is
tmp
undefined?Compile and run with
zig run undefined_slice_ptr_tuple_lit.zig
undefined_slice_ptr_tuple_lit.zig
:Result:
Something is going on here, because the integer value of
tmp.ptr
at runtime shows the sum ofundefined
and 1, an operation that completed at compile time and produced a compile-time-known pointer (as shown by the tuple type). Maybe another issue?Expected Behaviour
Cases 1 to 8 inclusive should have the same behaviour. Here are some options:
The text was updated successfully, but these errors were encountered: