Comment 1:

Labels changed: added repo-main, release-go1.4, os-windows.

Comment 2:

Actually, this is not specific to windows. It just happens that on Windows, HANDLE is
a void* type but it usually stores a small integer.
For example, this program will fail on unix (with tip, not 1.3.3, but I think the
underlying
reason is the same):
http://play.golang.org/p/IAddz4Q3ix
Pointer types from Cgo should be ignored by the GC (or conditionally ignored by GC
if it's invalid), because we forbid passing Go pointers to C (swig might be different,
but that's a different story.)

Labels changed: removed os-windows.

Status changed to Accepted.

Comment 3:

We had similar problem just a little while ago. https://golang.org/cl/152860043/
Alex

Comment 4:

yes, the windows problem is just a specific case of the general issue:
foreign pointers in Go structure.
I don't think we can label than separately as foreign pointers, so it
seems cmd/gc need to ignore them in pointer maps and then we
need a way for cgo to label certain fields as foreign pointers.

Comment 5:

Foreign pointers in Go structures are fine.  As long as they are really pointers.  In
hopefully rare cases where they are ambiguous (sometimes pointers, sometimes not), we
can use uintptr.
 I'm not sure if cgo knows the distinction, though.

Comment 6:

yes, real foreign pointers are fine, but unfortunately, cgo doesn't know which type of
pointers might
contain integers.
We disallow cgo to have Go pointers, so perhaps we can just not scan the cgo pointers as
pointers,
as they are guaranteed to not contain pointer to Go heap.
We can add a few blacklist, for example, HANDLE, but that is still not 100% safe.
Or we can use the heuristics that void * are problematic pointers.

Comment 7:

There is no plausible way to start enumerating the 'non-pointer' pointer types.
Don't use fake pointer types. Use uintptr instead of HANDLE, for example.

Comment 8:

Status changed to WorkingAsIntended.

Comment 9 by marcovanotti15:

Hi,
I don't think it is working as intended: as far as I know having fake pointers is valid
in C and it is widely used in windows API. IMO it shouldn't be intended to crash.
I think it should be a Won't Fix + a note in the cgo documentation saying that fake
pointers are not allowed. At least for me it wasn't obvious that the problem was that
HANDLE was a fake pointer and that it wasn't allowed in Go.