Skip to content
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

[Windows+MSVC] Inconsistent line terminators between Run/Debug #68

Open
BucketOfNubbins opened this issue Oct 20, 2024 · 3 comments
Open
Labels
unintuitive behaviour Technically correct but doesn't make logical sense zig-upstream Zig limitation (relevant issue mentioned in comments)

Comments

@BucketOfNubbins
Copy link

BucketOfNubbins commented Oct 20, 2024

I have a simple program to take input from the user, then print what the user typed right back out. Along with the length of the user's input.

I am using CLion.
My build.zig file is the standard auto-generated one.
My build configuration is normal except I added the "run" step to it in order to run my code.

const std = @import("std");

pub fn main() !void {
    var br = std.io.bufferedReader(std.io.getStdIn().reader());
    var bw = std.io.bufferedWriter(std.io.getStdOut().writer());
    const in = br.reader();
    const out = bw.writer();

    defer bw.flush() catch {};

    var arena = std.heap.ArenaAllocator.init(std.heap.page_allocator);
    defer arena.deinit();

    const alloc = arena.allocator();

    var input = std.ArrayList(u8).init(alloc);

    try in.readUntilDelimiterArrayList(&input, '\n', std.math.maxInt(usize));

    try out.print("{s}\n", .{input.items});
    try out.print("{}\n", .{input.items.len});

}

test "simple test" { 
    var list = std.ArrayList(i32).init(std.testing.allocator);
    defer list.deinit(); // try commenting this out and see if zig detects the memory leak!
    try list.append(42);
    try std.testing.expectEqual(@as(i32, 42), list.pop());
}

When running the program, it works as expected.

run_output

However stepping through the same program in the debugger, I get a different output.

debug_output

Here is a picture of some of the variables in the middle of a debug run.

mid_debug

It seems that the debugger is replacing the windows "\n" with the mac "\r", as well as printing an extra hello somewhere.

Below is the output of another debug run when I changed the code to look for "\r" instead of "\n"

debug_mac_end_line

I also did a normal run where the code is looking for "\r" as the delimiter, and signaled end of file with ctrl-d which resulted in the following (expected) error.

run_mac_end_line

I also have a different, but similar, project that can't debug at all as it just hangs on trying to connect to the debugger. However I don't know the steps to reproduce yet as this bug distracted me first.

@BucketOfNubbins
Copy link
Author

I forgot to add the version of Zig I have installed
0.14.0-dev.1930+4a2a0f50c

@FalsePattern FalsePattern added bug Something isn't working Critical labels Oct 22, 2024
@FalsePattern FalsePattern changed the title Debugging has different behavior than running [Windows+MSVC] Debugging has different behavior than running Oct 22, 2024
@FalsePattern
Copy link
Owner

Alright, I've managed to pinpoint the issue, it's in the MSVC debugger.
What happens is, on every user input, instead of \n as the line terminator, the debugger sends \r\n to the debugged process, so you will need to handle both cases to be fully platform-agnostic, unfortunately I cannot fix this from ZigBrains.

@FalsePattern FalsePattern added unintuitive behaviour Technically correct but doesn't make logical sense and removed bug Something isn't working Critical labels Oct 25, 2024
@FalsePattern
Copy link
Owner

See also: ziglang/zig#6754

@FalsePattern FalsePattern changed the title [Windows+MSVC] Debugging has different behavior than running [Windows+MSVC] Inconsistent line terminators between Run/Debug Oct 25, 2024
@FalsePattern FalsePattern pinned this issue Oct 25, 2024
@FalsePattern FalsePattern added the zig-upstream Zig limitation (relevant issue mentioned in comments) label Oct 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
unintuitive behaviour Technically correct but doesn't make logical sense zig-upstream Zig limitation (relevant issue mentioned in comments)
Projects
None yet
Development

No branches or pull requests

2 participants