Skip to content

Conversation

mbrock
Copy link

@mbrock mbrock commented Sep 25, 2025

The writeSplatHeaderLimitFinish logic correctly takes the limited prefix slice of the header, but fails to chop off excess in the data vector slices, causing a drain longer than the limit.

I spotted this by accident, and found one usage in std, in the HTTP chunked encoding writer, and the issue #24944 that I speculate this commit will fix. I was able to partly reproduce it on Linux but only by disabling sendfile and some other weird kludges.

First time hacking the Zig std. I verified tests failing and then passing with

zig test lib/std/std.zig --zig-lib-dir lib

The `writeSplatHeaderLimitFinish` logic correctly takes the limited
prefix slice of the header, but fails to chop off excess in the data
vector slices, causing a drain longer than the limit.

I spotted this by accident, and found one usage in std, in the HTTP
chunked encoding writer, and the issue ziglang#24944 that I speculate this
commit will fix. I was able to partly reproduce it on Linux but only
by disabling sendfile and some other weird kludges.
@squeek502
Copy link
Member

squeek502 commented Oct 5, 2025

This looks like a nice bug fix, but, unfortunately, this does not fix #24944 (see #24944 (comment))

Comment on lines +934 to +942
// Test inspired by a bug in one of Io.Writer's write helpers.
//
// The fix doesn't touch the HTTP code, but the BodyWriter is
// from what I can tell the only affected code in std.
//
// Possibly the cause of https://github.com/ziglang/zig/issues/24944
// wherein the `zig std` server on Windows, due to lack of sendfile,
// drains the streaming sources tarball by doing vector writes
// of file contents in the chunked body stream.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This type of information should go in the commit message rather than a comment. I'd say just remove the comment (without moving it to the commit message), since the fix in this PR doesn't actually affect the problem in #24944 (see my other comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants