bytealg.MakeNoZero has indirectly already leaked to the end user

[Jérôme LAFORGE]

Happy New Year everyone!

The documentation for bytealg.MakeNoZero states: "do not leak to the end user." However, in practice, there is at least one hack to access it using the unsafe package. Wouldn't it be simpler to avoid this kind of hack by directly exposing this function within the unsafe package, since this function has already indirectly leaked to the end user?

The hack:

func MakeSlice(c int) []byte {
var sb strings.Builder
sb.Grow(c)
s := unsafe.StringData(sb.String())
return unsafe.Slice(s, c)[:0]
}

[Benny Siegert]

On Sun, 4 Jan 2026, Jérôme LAFORGE wrote:

> Happy New Year everyone!
> The documentation for bytealg.MakeNoZero states: "do not leak to the end user." However, in practice, there is at
> least one hack to access it using the unsafe package. Wouldn't it be simpler to avoid this kind of hack by directly
> exposing this function within the unsafe package, since this function has already indirectly leaked to the end
> user?

The part of the comment about "leaking to the end user" was not about the
MakeNoZero API but rather about the uninitialized memory it returns. You
need to make sure you overwrite all the memory with something useful
before handing its content to someone else.

--
Benny

[Filippo Valsorda]

The question here is "do we want a documented unsafe.MakeUninitialized API with a forever backwards-compatibility promise?" You can open a proposal to discuss that. The fact that you can already get that through this specific unsupported unsafe strings.Builder hack is kind of inconsequential: everything leaks through sufficient unsafe use.

--

You received this message because you are subscribed to the Google Groups "golang-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/golang-dev/b7462d5b-a734-4f5d-b8c7-5ff7fd8fa264n%40googlegroups.com.

[t hepudds]

Hi Jérôme, 

FWIW, just exposing some flavor of bytealg.MakeNoZero is likely more dangerous than you might guess, including with regards to respecting the Go memory model as far as I understand.

I just filed a related issue based on some observations Rick Hudson made while reviewing the runtime.freegc work.

Rick pointed out what seems to be a long-standing problem with current uses of bytealg.MakeNoZero in the standard library and other callers of mallocgc with needzero=false. Based on that, I filed:

   #77074 -- "runtime, strings, bytes: missing publication barriers after mallocgc with needzero=false and bytealg.MakeNoZero"
   https://github.com/golang/go/issues/77074

Separately, my guess would be that more directly exposing bytealg.MakeNoZero to end-users is relatively unlikely based on the goals of the Go project.

Best regards,

--thepudds

To view this discussion visit https://groups.google.com/d/msgid/golang-dev/fecc9b8b-914a-40bc-bcbb-d14099e57566%40app.fastmail.com.

[Jérôme LAFORGE]

It is more clear for "leaking to end user".

Many thank Benny

[Jérôme LAFORGE]

Please find this modest proposal (be kind, it is my first one): https://github.com/golang/go/issues/77077

[Jérôme LAFORGE]

Hi thepudds.

Thank for pointing me this issue.