std.mem.eql changes values memory

[Tiltimus]

Zig Version

0.12.0-dev.3029+723d13f83

Steps to Reproduce and Observed Behavior

I was trying to write a basic print for a date. When I ran this the first print will be:

BEFORE a: { 50, 48, 50, 52, 45, 48, 52, 45, 48, 54 } b: { 50, 48, 50, 52, 45, 48, 52, 45, 48, 54 }

and the second

AFTER a: { 8, 192, 52, 0, 0, 0, 0, 0, 8, 192 } b: { 50, 48, 50, 52, 45, 48, 52, 45, 48, 54 } equal: false

Im pretty new to zig so there is a high chance I am doing something wrong. Tried to hunt for where it could possibly be changing the value and it seems to happen before eqlBytes(sliceAsBytes(a), sliceAsBytes(b). I couldn't quite work out where though.

const std = @import("std");

pub fn main() !void {
    const actual = try print(2024, 4, 6);
    const expected = "2024-04-06";

    std.debug.print("BEFORE a: {any} b: {any}\n", .{ actual, expected });

    const areEqual = std.mem.eql(u8, actual, expected);

    std.debug.print("AFTER a: {any} b: {any} equal: {}\n", .{ actual, expected, areEqual });
}

pub fn print(year: u14, month: u4, day: u5) ![]u8 {
    var buf: [10]u8 = undefined;

    return try std.fmt.bufPrint(
        &buf,
        "{d:0>4}-{d:0>2}-{d:0>2}",
        .{
            year,
            month,
            day,
        },
    );
}

Expected Behavior

I would expect the memory from the first value I passed in not to change.

[Rexicon226]

The issue here is that you're creating a stack variable buf and then returning a pointer to it which will make reading from it invalid. Either allocate in print, or create the buf in a higher scope, like in main.

[Tiltimus]

Oh okay me being dumb thanks for the speedy response ! :)

[nektro]

not knowing something doesnt make you dumb :)

[bronze1man]

The issue here is that you're creating a stack variable buf and then returning a pointer to it which will make reading from it invalid.

Is it very hard to implement to print an error in compiler when it seeing code like this? Or zig deliberately doesn't do this?

[nektro]

its planned, just hasn't been implemented yet #5725

[silversquirl]

That proposal isn't accepted, so saying "it's planned" is a bit misleading