On Tuesday, 29 August 2017 18:21:58 UTC+1, Ian Lance Taylor wrote: > > On Tue, Aug 29, 2017 at 8:53 AM, Phil Noel <ph...@noels.org.uk > <javascript:>> wrote: > > > > I believe the error is that _cgoCheckPointer is scanning the _cgo0 > variable > > (ie c_msg, ie type *_Ctype_struct_tagMSG) and detecting the > > hwnd:(win._Ctype_HWND)(0x5a0cdc) value 0x5a0cdc is a pointer to > something on > > the Go heap. > > > > In reality this value is assigned by Windows and is actually the window > > handle. > > > > Initially I was just going to force my win.HWnd to be a uintptr (as > > effectively its a handle). However the cgo code knows its actually an > opaque > > pointer and thus treats it as a real pointer (unsafe.Pointer). So I > think > > forcing my code to use a uintptr won't help. Also it seems that general > > guidelines are to use unsafe.Pointer if its a pointer (or appears to > be). > > I didn't try to fully understand this code, but this point seems > problematic. From Go's perspective, a value is either a pointer or > not. There can't be any waffling on that. If win.HWnd is a handle, > not a memory address, then you must treat it as a uintptr. If it is a > pointer--if you could reliably convert it to a pointer type via > unsafe.Pointer and dereference it to get valid data--then you must > treat it as a pointer. From Go's perspective there is no such thing > as an opaque pointer or a value that appears to be a pointer. It's a > pointer or it isn't, and type must correspond. > > Ian >
Thanks Ian, I thought this maybe the offical answer. I also couldn't see how Go could recognise this as a "not real" pointer. Its unfortunate that the main windows header (windows.h) has this defined as a pointer and therefore cgo will treat it as a pointer. So even if I force my Go version of the structure (win.Msg) to use uintptr (ie win.HWnd) it will fail once it hits the cgo code (which will use the pointer based on the windows.h file ie *_Ctype_struct_HWND__). This is because my Go Msg structure is cast to the cgo version C.MSG (based on windows.h) I think for my problem I will just create a mini version of windows.h that has only the functions I require. I can then pretend that MSG is an opaque pointer so cgo won't see inside it (therefore unable to check the fake pointer). Or I can wrap the troubling functions inside my own C code to hide the windows part of this. I'm also a little surprised I could not find anyone else with this problem as TranslateMessage is pretty much a standard Windows GUI required function. Thanks for your quick reply. Phil -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
