Agreed. If a Go library uses unsafe I avoid it. > On Jul 27, 2021, at 9:54 AM, 'Axel Wagner' via golang-nuts > <golang-nuts@googlegroups.com> wrote: > > >> On Tue, Jul 27, 2021 at 4:15 PM Steve Roth <st...@rothskeller.net> wrote: > >> The implementation of io.WriteString appears to allocate a new byte slice >> and copy the string into it: >> w.Write([]byte(s)) > > Only if the writer does not implement `io.StringWriter`. Avoiding this > allocation where possible is exactly why `io.StringWriter` exists. > >> Many third party libraries avoid the allocation and copy with techniques >> like: >> var b []byte >> sh := (*reflect.StringHeader)(unsafe.Pointer(&s)) >> bh := (*reflect.SliceHeader)(unsafe.Pointer(&b)) >> bh.Data = sh.Data >> bh.Len = sh.Len >> bh.Cap = sh.Len >> w.Write(b) >> I've seen so many different packages do this that it almost seems like a >> preferred idiom. Yet, it doesn't seem to be guaranteed safe by the rules in >> the "unsafe" package documentation; rule 6 comes close to allowing it but >> doesn't quite get there. And the fact that the standard library doesn't use >> it, in an obviously applicable place, is telling. >> >> So, what's the deal here? Is it safe or not? > > No, that code is broken. It makes assumptions about the implementation of > `Write`, which is *documented*, but not enforced by the compiler - namely, > that `Write` may not retain a reference to the `[]byte` and may not modify > its contents. If such an incorrect `io.Writer` is used with a library like > this, it might break the program in strange and unforseen ways. > >> Can I use it in my own code? > > There are occasions where it is safe. For example, strings.Builder does a > similar thing in a safe way. > So, as with all unsafe: If you know it's safe, it's fine to use. Otherwise, > stay away. > >> Must I shun libraries that use it? (Must I read the source code of every >> library I use, to see whether it uses it?) > > Unfortunately there is no way to guarantee that a dependency contains good > code. > This particular issue should be reasonably easy to find by grepping for > `unsafe`, which is a good practice if you want to avoid potentially unsafe > code anyway. > >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/CAAnpqKHoA74DfM5765vUfrH4V6RpBxg1DTkfn3ScN6MhjQwRTQ%40mail.gmail.com. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEf6NbkAvDRs6QFO7LDggh-n-6mT3aBnG3gNh678Z6Z1g%40mail.gmail.com.
-- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/BEFE6027-3616-4654-A7D5-FBC167D0CDFF%40ix.netcom.com.
