Fix invalid usage of reflect.SliceHeader

[cuonglm]

Using reflect.Sliceheader as plain struct violates the unsafe pointer
rule 6th.

[ti-mo]

Hi @cuonglm, thanks for the patch! Could you leave the comments in place? Those still apply regardless of this fix.

[cuonglm]

Hi @cuonglm, thanks for the patch! Could you leave the comments in place? Those still apply regardless of this fix.

Hi @ti-mo, would you mind elaborating how can we solve this with unsafe.Slice?

AFAICT, unsafe.Slice need to work with pointer, while unsafe.Pointer does not have pointer semantic.

[ti-mo]

Hi @cuonglm, I mostly meant the comment about removing support for marshaling unsafe.Pointers, that's something we should still consider.

I just tried playing around with unsafe.Slice a bit, and by the looks of it, it makes use of type params already? nvm, this just seems inherent to ArbitraryType. Actually, seems like unsafe.Slice might be a generic function after all. Its return type magically changes based on its input parameter. 🙂

The following seems to work and passes our current test suite:

	case unsafe.Pointer:
		dst := unsafe.Slice((*byte)(value), len(buf))
		copy(dst, buf)
		return nil

If I understand correctly, no longer need to call runtime.KeepAlive on value since we no longer take out a uintptr.

Until we drop support for pre-1.17, I would still go for your solution as the docs indeed prescribe that only existing slices must be reinterpreted using reflect.SliceHeader, and the caller should never allocate their own.

cc @lmb

[cuonglm]

@ti-mo Thanks for clarification! I restored + updated the comment to make it a bit clearer.

[ti-mo]

@cuonglm Thanks!