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

os: File.WriteString() makes a copy of the string #26210

adam-azarchs opened this issue Jul 4, 2018 · 2 comments

os: File.WriteString() makes a copy of the string #26210

adam-azarchs opened this issue Jul 4, 2018 · 2 comments


Copy link

@adam-azarchs adam-azarchs commented Jul 4, 2018

What version of Go are you using (go version)?


Does this issue reproduce with the latest release?


What operating system and processor architecture are you using (go env)?

linux / amd64

What did you do?

package main

import "os"

func main() {
    os.Stdout.WriteString("hello world\n")

What did you expect to see?

File's WriteString should not be making a copy of the string.

What did you see instead?

In the disassembly,

func (f *File) WriteString(s string) (n int, err error) {
  465994:       48 8b 44 24 78          mov    0x78(%rsp),%rax
        return f.Write([]byte(s))
  465999:       48 89 44 24 10          mov    %rax,0x10(%rsp)
  46599e:       e8 1d 90 fd ff          callq  43e9c0 <runtime.stringtoslicebyte>

runtime.stringtoslicebyte makes a copy.

To pick just one example, the io.WriteString method knows to look for the WriteString method on io.Writer objects in order to avoid an extra copy. Lots of other libraries also use it to avoid a copy.

This is closely related to to several other issues, including #2205 and #18822. While it would be great to elide the copy through compiler analysis, that bug has been open for nearly 7 years now. Even if that feature were implemented in the compiler, it wouldn't help without some kind of explicit annotation to syscall.Write to let the compiler know that nothing is writing to the byte array through the unsafe pointers it takes. The good news is that unlike many of the other cases around those bugs, the public API required for getting round that missing compiler feature is already there.

In order to fix this, we'd need to add WriteString methods for the various internal/poll/FD implementations. Easy enough. The bad news is that those all call some version of syscall.Write. While that method is already a mess of unsafe pointers, so a syscall.WriteString version of the method would be a nearly exact copy/paste, the syscall package is "locked down" - adding a new method there is likely to incur added resistance. However, given the ubiquity of writing strings to files, it seems like a good thing to fix. Alternatively, the os package could just use one of the various unsafe tricks to avoid drilling down through those other API layers.

Copy link

@gopherbot gopherbot commented Jul 19, 2018

Change mentions this issue: cmd/go: preserve %SYSTEMROOT% in TestScript on Windows

Copy link
Contributor Author

@adam-azarchs adam-azarchs commented Jun 10, 2021

I see that a fix for this is listed in the draft release notes for go 1.17. Closing this as a duplicate of #42406.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants