gcc version if helpful,
gcc (GCC) 8.2.1 20180831

cgo-exported functions are not allowed to return pointers to Go memory. (The Go garbage collector does not see the C stack or heap.)

See https://golang.org/cmd/cgo/#hdr-Passing_pointers.

Go code may pass a Go pointer to C provided the Go memory to which it points does not contain any Go pointers.

@bcmills
The pointer which I'm passing doesn't contain any Go Pointer.
C code also doesn't pass around Go pointer anywhere else.
Go-owned value is not being zeroed, as stated in the title.

I don't think the problem is related to GC, as I was able to see result when sleeping by one millisecond.
I assume(not sure), a seperate goroutine is being started to assign values, and by the time it assigns it is returning, or some optimization bug, or cgo bug.

	res := make([]uint8, 2)

allocates a slice in Go memory.

	return hdr.Data

returns a Go-owned pointer as a uintptr. The prohibition on passing Go pointers applies even if those pointers are represented as uintptr.

The relevant part of the cgo rule is this:

A Go function called by C code may not return a Go pointer (which implies that it may not return a string, slice, channel, and so forth). A Go function called by C code may take C pointers as arguments, and it may store non-pointer or C pointer data through those pointers, but it may not store a Go pointer in memory pointed to by a C pointer. A Go function called by C code may take a Go pointer as an argument, but it must preserve the property that the Go memory to which it points does not contain any Go pointers.

Note that values of some Go types, other than the type's zero value, always include Go pointers. This is true of string, slice, interface, channel, map, and function types.

Source which you have pointed out means these types contain Go pointers.

Go pointer (which implies that it may not return a string, slice, channel, and so forth)

@bcmills consider re-opening the issue.

Go code may pass a Go pointer to C provided the Go memory to which it points does not contain any Go pointers.

@bcmills
The pointer which I'm passing doesn't contain any Go Pointer.
C code also doesn't pass around Go pointer anywhere else.
Go-owned value is not being zeroed, as stated in the title.

I don't think the problem is related to GC, as I was able to see result when sleeping by one millisecond.
I assume(not sure), a seperate goroutine is being started to assign values, and by the time it assigns it is returning, or some optimization bug, or cgo bug.

• The pointer which I'm passing doesn't contain any other Go Pointer.

	res := make([]uint8, 2)

allocates a slice in Go memory.

	return hdr.Data

returns a Go-owned pointer as a uintptr. The prohibition on passing Go pointers applies even if those pointers are represented as uintptr.

But the pointer which I'm passing doesn't contain any other Go pointer, which means I can pass it to C.

The rule, which @bcmills quoted above is: "A Go function called by C code may not return a Go pointer." You are looking at the rule for pointers that may be passed from Go code when calling C code. That is not what your program is doing. Your program is C code calling a Go function. That rule for that case is that the Go function may not return a Go pointer. It's not OK for an exported Go function to return a Go pointer that does not point to other Go pointers; an exported Go function may not return a Go pointer at all.

@ianlancetaylor You cleared the point, but

A Go function called by C code may take a Go pointer as an argument, but it must preserve the property that the Go memory to which it points does not contain any Go pointers.

If a Go function which is called by C code can take a Go pointer as argument, then how did the C program get the Go pointer in first place.

If a Go function which is called by C code can take a Go pointer as argument, then how did the C program get the Go pointer in first place.

The C function gets the Go pointer by itself being called by a Go function. (If you have a Go→C→Go call chain, the values passed in the Go→C call are pinned for the duration and therefore available for the C→Go call, since the C→Go call must return before the Go→C call can return.)

@bcmills thanks a lot for clearing up.