Also posted on Stack Overflow:
Why is more memory being used when encoding a slice of structs with smaller
length
https://stackoverflow.com/questions/78136093/why-is-more-memory-being-used-when-encoding-a-slice-of-structs-with-smaller-leng
On Monday, March 11, 2024 at 12:3
Go version
go version devel go1.23-e8b5bc63be linux/amd64
When using binary.Write for encoding a slice of structs, I encountered some
weird behaviour where memory allocations in a particular path was more than
I expected.
I wrote some benchmarks in the standard library's encoding/binary packag
It's not quite what you're after, but FWIW the gohack command (
github.com/rogpeppe/gohack) knows enough to download arbitrary Go modules
including the VCS checkout. You might find it useful, I guess.
For example:
% gohack get -vcs golang.org/x/mod
creating golang.org/x/mod@v0.16.0
golang.org/x/m
I think you put this issue on the Go issue
board? https://github.com/golang/go/issues/66239
Seems like the bug has been confirmed or at least it's being looked at
On Monday, March 11, 2024 at 2:04:19 PM UTC Jay Goel wrote:
> Hello,
>
> I believe there is a bug where, on Mac, reading a named pipe
When using `binary.Write` for encoding a slice of structs, I encountered
some weird behaviour where memory allocations in a particular path was more
than I expected.
I wrote some benchmarks in the standard library's encoding/binary package
to demonstrate this.
func BenchmarkWriteSlice1000Str
Hello,
I believe there is a bug where, on Mac, reading a named pipe with
O_NONBLOCK is blocking on Read(). I am not able to reproduce this on Linux.
This example is on go version go1.22.1 darwin/arm64, and I am running an M1
2020 macbook with OS version 12.5 (21G72).
I believe there is some
What exactly beside the information in https://go.dev/blog/govulncheck
and especially https://go.dev/doc/tutorial/govulncheck do you want
to discuss?
V
On Monday 11 March 2024 at 00:49:17 UTC+1 Colton Freeman wrote:
> Disregard. Figured out the tool (a little better). Would still love to
> chat
