Fix unsafe use of pointers in sample code

[zolstein]

benchmark_marshaler_test.go and its copy in the README demonstrated
unsafe conversion of uintptr -> unsafe.Pointer. Fixing this will
hopefully reduce the likelihood that users will write unsafe code.

---

I noticed the unsafety while reading this blog post, which says:

In effect, once we’ve converted an unsafe.Pointer to uintptr, we cannot safely convert it back to unsafe.Pointer, with the exception of one special case:

If p points into an allocated object, it can be advanced through the object by conversion to uintptr, addition of an offset, and conversion back to Pointer.

In order to perform this pointer arithmetic iteration logic safely, we must perform the type conversions and pointer arithmetic all at once

As I understand, the reason that the old version was unsafe and this is not is that Go reserves the right for the garbage-collector to move objects, which may invalidate the uintptr pointing to the struct field before the field can be accessed. However, by doing the conversion to a uintptr, the pointer arithmetic, and the conversation back to an unsafe.Pointer in one statement, the value retains its pointer semantics through the whole operation and is guaranteed to be updated if the underlying object is moved.

(I don't believe the current GC actually moves objects, so probably the old version would always work... unless / until a new version of Go introduces this, at which point something like this could cause very rare breakages.)

Even though this code is meant as a benchmark and sample use-case, since users will try to copy this code to write similar code, it's probably best to demonstrate good practices that won't break in the future.

go vet validates that the old version was unsafe and the new version is not. Running the benchmark with the old and new versions of the code seemed to show equivalent performance and no additional allocations.

[goccy]

You are right. Thank you for the contribution !