How to copy a smaller slice into a bigger slice?

Help
,
1

Hi, I have this code:

// Copies slice `s` into the requested line
pub fn set_line(line: usize, s: []u8) !void {
    if (line < 0 or line > winsize.row) {
        return error.OutOfBounds;
    }

    if (s.len > winsize.col) {
        return error.BufferTooBig;
    }

    // If the slice isn't as big as winsize.col then the line is first cleared
    if (s.len < winsize.col) {
        @memset(buffer[line], 0);
    }

    @memcpy(buffer[line], s);
}

The issue is I get the following error:
panic: source and destination arguments have non-equal lengths

How would I copy s into buffer[line] even if buffer[line] is bigger than s?

2

Assuming that buffer[line] is a slice as well, then you simply needs to reslice it to the length of s, eg as buffer[line][0..s.len].

4 Likes
3

You can use a range on a slice to create a new slice with whatever length you want, including the length of a smaller slice.

const std = @import("std");

pub fn main(_: std.process.Init) !void {
    var big: [8]u8 = @splat('!'); // !!!!!!!!
    var sml: [4]u8 = @splat('?'); // ????

    const b: []u8 = &big;
    const s: []u8 = &sml;

    const offset = 2;
    @memcpy(b[offset .. offset + s.len], s);

    std.debug.print("{s}", .{b}); // !!????!!
}
3 Likes
4

Thanks for the replies

5

@memcpy(b[offset .. offset + s.len], s);

This can also be written as: @memcpy(b[offset .. ][0..s.len], s);, and is considered more idiomatic. You’ll see that pattern alot in zig std.

3 Likes
6

That’s very ugly! I understand the concept of a slice of a slice but it is (probably) consuming more stack memory for the same thing and it looks like an array of arrays from C.

Me not like >:C

7

It probably doesn’t. It’s just additional pointer arithmetic.

8

It is not a slice of a slice, don’t judge a construct before you understand it.

Edit: for me a slice of a slice is [][]u8 and similar, this just does slicing and re-slicing and because the compiler sees the two slicing operations after another it can treat them similarly to the other single slicing. I was speaking from the more general case where b is a multi-item pointer to begin with instead of a slice (which I admit was an oversight on my part) and in that case I find the double slicing operation much prettier than the arithmetic version, that was the main point I wanted to make.

The first part b[offset .. ] results in a slice multi-item pointer [*]u8 these pointers don’t have an associated length and the pointer points to the offset item, so this part does the offsetting.

The second part [0..s.len] re-slices the multi-item pointer, returning a slice and thus gives it a defined length. to the final length.

It is semantically and memory wise equivalent to the other way of writing it, but it avoids repeating offset twice and doing manual addition, further in contexts where the length is comptime known it has the added benefit of resulting in a pointer to array (instead of a slice), which is coerce-able to a slice, but doesn’t need to store the length because it is comptime known.

3 Likes
9

You got that wrong I think:

const std = @import("std");
pub fn main(init: std.process.Init) !void {
    const s1 = try init.arena.allocator().alloc(u8, 8);
    var offset: u32 = 4;
    @compileLog(s1[offset..]);
    offset = 5;
}

This prints:

Compile Log Output:
@as([]u8, [runtime value])
2 Likes
10

Thanks for the patronizing and pedantic statement, but your knowledge doesn’t seem consistent with what the compiler is giving me back.

You first statement doesn’t seem to be true, since b[offset .. ] does not result in a multi-item pointer [*]u8:

const c = b[offset..];
std.debug.print("{}", .{@TypeOf(c)}); // []u8

Your second statement also doesn’t seem true. The four combinations of (runtime, comptime) and (cool syntax, ugly syntax) return exactly the same instructions when using any release flag.

image
image362Ă—257 14.4 KB

Also, my statement about consuming more memory seems accurate, but only when you are not using any release flag and comparing runtime versions of the function. In this case, you can see a difference from ugly syntax to pretty syntax in which case the pretty version do use less instructions and memory.

image
image1841Ă—1123 243 KB

11

I can’t think of a use case where you’d want performance so much that you’d rather use slice[idx..idx + len] instead of slice[idx..][0..len], and still not use any release flag.

2 Likes
12

Maybe in the case of debugging a recursive runtime slice-creating function…

But yeah pretty useless info.