Skip to content

Stage1 bug: runtime copy of statically-dereferenced *[0:S]T doesn't hold sentinel #6905

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
rohlem opened this issue Nov 1, 2020 · 0 comments
Labels
bug Observed behavior contradicts documented or intended behavior stage1 The process of building from source via WebAssembly and the C backend.
Milestone

Comments

@rohlem
Copy link
Contributor

rohlem commented Nov 1, 2020

Slicing with length of 0 returns a slice with .len = 0, .ptr = undefined. See #4771 for discussion on that.
This issue is probably related, but when testing I found out that sentinel-terminated slices actually work, so I can't find a source of UB anywhere in what I'm doing. Test case:

const expect = @import("std").testing.expect;
test "sentinel-terminated 0-length slices" {
    var u32s: [4]u32 = [_]u32{0, 1, 2, 3};

    var index: u8 = 2;
    var slice = u32s[index..index:2];
    var array_ptr = u32s[2..2:2];
    const comptime_known_array_value = u32s[2..2:2].*;
    var runtime_array_value = u32s[2..2:2].*;

    expect(slice[0] == 2);
    expect(array_ptr[0] == 2);
    expect(comptime_known_array_value[0] == 2);
    expect(runtime_array_value[0] == 2); //fails
}

Inspecting the addresses with std.debug.print, comptime_known_array_value and runtime_array_value have the same address... whatever that means.
My best explanation would be that the compiler gets confused over whether it needs to separately allocate and copy the sub-array or not, and so that memory is left uninitialized.

@rohlem rohlem changed the title Stage1 bug: statically-sliced runtime *[0:S]T doesn't point to sentinel Stage1 bug: runtime copy of statically-dereferenced *[0:S]T doesn't hold sentinel Nov 1, 2020
@andrewrk andrewrk added bug Observed behavior contradicts documented or intended behavior stage1 The process of building from source via WebAssembly and the C backend. labels Nov 1, 2020
@andrewrk andrewrk modified the milestones: 0.8.0, 0.9.0 Nov 1, 2020
@andrewrk andrewrk modified the milestones: 0.9.0, 0.10.0 May 19, 2021
wooster0 added a commit to wooster0/zig that referenced this issue Dec 7, 2022
wooster0 added a commit to wooster0/zig that referenced this issue Dec 7, 2022
wooster0 added a commit to wooster0/zig that referenced this issue Dec 7, 2022
wooster0 added a commit to wooster0/zig that referenced this issue Dec 8, 2022
wooster0 added a commit to wooster0/zig that referenced this issue Dec 8, 2022
wooster0 added a commit to wooster0/zig that referenced this issue Dec 9, 2022
@andrewrk andrewrk modified the milestones: 0.12.0, 0.11.0 Dec 10, 2022
kcbanner pushed a commit to kcbanner/zig that referenced this issue Dec 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Observed behavior contradicts documented or intended behavior stage1 The process of building from source via WebAssembly and the C backend.
Projects
None yet
Development

No branches or pull requests

2 participants