I'm not sure exactly what you are asking for here. What does "accessing memory" mean here? Do you mean allocating, or just reading & writing?

Reading and writing can be done on non-Go memory just as you would on Go heap memory. Cast the unsafe.Pointer to a concrete pointer type and go at it. (With the large caveat that the non-Go memory cannot contain pointers into the Go heap.)

For allocating, there are many possibilities. Package unsafe probably isn't the place to document those. For instance, sycall.Mmap or C.malloc would be documented in their packages, not in unsafe.

The problem is that the non-Go memory might contain invalid pointers, which proper C callers will never dereference.

I see. Yes, we should probably say something about pointers-which-are-not-actually-pointers.
The short answer is use uintptr for those. You can't actually dereference them in Go, so there's no benefit to using unsafe.Pointer.

Note that C.malloc never returns an invalid pointer.

Note that there is only a potential problem when a value is copied into Go memory one way or another. A pointer value at rest in non-Go memory is never a problem.

Is it okay to have a pointer in the Go heap, that points to memory not allocated by Go?

Yes, as long as the pointer is to a valid address.

(A pointer to an entirely-unmapped address is not ok in general, but a pointer to an address mapped in by C code or by an mmap system call should be fine.)

I am a bit confused here: non-Go memory could have any value at all, so the Go runtime obviously needs to treat it specially. Why does it access the memory at all if it can’t use its value?

The Go runtime does not access non-Go memory. But the Go runtime does make some sanity checks on pointer values, and crashes if it finds a pointer that holds a clearly invalid value--such as a pointer that can't possibly point to any address mapped into memory.

I would encourage you to take a step back with your questions, which seem very specific and potentially confusing. Is there a broader question that you are trying to ask?

The short answer is that the current behavior makes automatic binding generation much more difficult.

The short answer is that the current behavior makes automatic binding generation much more difficult.

Could you elaborate? What is "automatic binding generation" and how is it made difficult?

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

The short answer is that the current behavior makes automatic binding generation much more difficult.

Could you elaborate? What is "automatic binding generation" and how is it made difficult?

Tools that generate Go code from C header files do not know if something with a pointer type in C is actually a valid pointer. Some C APIs use pointers to refer to non-pointer data, but this cannot be determined by just parsing C headers.

Some C APIs use pointers to refer to non-pointer data

Those APIs are not portable. Per the C11 standard, “the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation.”

When passed to Go as an unsafe.Pointer, it happens to be equivalent to a trap representation.

Some C APIs use pointers to refer to non-pointer data

Those APIs are not portable. Per the C11 standard, “the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation.”

They are portable to virtually all platforms I know of.