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

1.10.3

Does this issue reproduce with the latest release?

Yes

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.