Hello, I wish to call some Windows functions, some of which take pointers to types which themselves contain pointers. For this purpose I intended to use golang.org/x/sys/windows/mkwinsyscall.go and not cgo; in past I have implemented a package that uses WASAPI by generating "syscall" bodies with mkwinsyscall.go and doing syscall.SyscallN to call virtual functions in COM objects and so have some prior experience.
Now I want to call RegisterClassW which takes a pointer to WNDCLASSW as its parameter. One of the members of WNDCLASSW is lpszClassName of LPCWSTR type (UTF-16 string). This puzzled me as to how I should approach allocating storage for that string? Taking into account Go specification making special reservations for pointers passed to cgo calls (https://golang.org/cmd/cgo/#hdr-Passing_pointers; my guess is that it is intended to facilitate possible implementations of moving garbage collectors in future) I thought I would have to allocate storage with, say, C.malloc, but that would require using cgo which so far I have not had to use. I looked into how Go standard library handles this, and I found crypto/x509/root_windows.go checkChainSSLServerPolicy (https://github.com/golang/go/blob/fa98f46741f818913a8c11b877520a548715131f/src/crypto/x509/root_windows.go#L103) build a chain of pointers and then pass it to syscall.CertVerifyCertificateChainPolicy, which is in violation of the cgo passing pointers requirement. Although this particular case does not use cgo, I believe pointer passing restriction would still apply to it. All of this made me puzzled, should I store a pointer returned by syscall.UTF16PtrFromString (golang.org/x/sys/windows.UTF16PtrFromString) or use C.malloc+copy? Or, if the answer isn't straightforward, is it fair to think that use of pointer returned by UTF16PtrFromString is more likely to break with newer versions of go than C.malloc+copy or is it expected that there will be some amendments made to that function when a hypothetical moving GC implementation lands? -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/fd24768a-468b-4637-94d2-f9d103f6802dn%40googlegroups.com.
