Invalid use of reflect.SliceHeader and reflect.StringHeader could lead to memory corruption

[lthibault]

In integration_test.go, the following is flagged by go vet as a possible misuse of reflect.SliceHeader and reflect.StringHeader.

A cursory google search supports the notion that this is a bug.

func unsafeBytesToString(b []byte) string {
	slice := *(*reflect.SliceHeader)(unsafe.Pointer(&b))
	hdr := reflect.StringHeader{Data: slice.Data, Len: slice.Len}
	return *(*string)(unsafe.Pointer(&hdr))
}

Two questions:

1. Couldn't this be simplified to *(*string)(unsafe.Pointer(&b))?
2. I appreciate that this is running in benchmarking code, but perhaps we should just opt for a good ol' fashioned string(b) here?

The impact is sure to be minor since this is just running in tests, but (a) I prefer to do things the right way and (b) I don't like it when my linter yells at me.

Thoughts?

[lthibault]

cc @zenhack

[zenhack]

1. Yes, I think this simplification is correct.
2. It seems likely that that would dominate the benchmark, so I'm hesitant to just do that. I wish the intentions of the benchmark were more explicitly spelled out; it would make it easier to try to find a safe way to write something that does the right thing.

[lthibault]

Ok, I'll just apply the *(*string)(unsafe.Pointer(&b)) correction.

[lthibault]

Closing optimistically.