Amending question above: is it ok for a function that takes pointer to a pointer (so f(x *unsafe.Pointer) or f(**T)) to write a pointer (*x = unsafe.Pointer(...) or *x = (*T)(...)) or should it store an uintptr (as in f(x *uintptr)) and that uintptr then be cast to a pointer to appropriate type?
On Monday, October 26, 2020 at 4:23:13 AM UTC+2 Constantine Shablya wrote: > 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/8caad08a-d1ee-4757-8e56-cbe08772e80bn%40googlegroups.com.
