如何优雅地从`syscall.Syscall()`的使用中迁移？

Question

The syscall package is deprecated. Assume I have the following code which I would like to migrate to something that is not deprecated:

someGoObject := &struct{int; float32}{5, 45.4}
syscall.Syscall6(someProc.Addr(), 1, uintptr(unsafe.Pointer(someGoObject)), 0, 0, 0, 0, 0)

whereby someProc is of type *syscall.LazyProc ( Windows ).

The sys subrepository , which the syscall docs recommend to use instead, no longer offers a function akin to syscall.Syscall , and if the desired function is not implemented over there, one might attempt to solve the problem the following way, and believe the job is done:

someProc.Call(uintptr(unsafe.Pointer(someGoObject)))

whereby now someProc is of type *windows.LazyProc .

However, if we did this, we would not get one of syscall.Syscall 's (and friends') guarantees, because LazyProc.Call() is not implemented in assembly :

(4) Conversion of a Pointer to a uintptr when calling syscall.Syscall.

The Syscall functions in package syscall pass their uintptr arguments directly to the operating system, which then may, depending on the details of the call, reinterpret some of them as pointers. That is, the system call implementation is implicitly converting certain arguments back from uintptr to pointer.

If a pointer argument must be converted to uintptr for use as an argument, that conversion must appear in the call expression itself:

 syscall.Syscall(SYS_READ, uintptr(fd), uintptr(unsafe.Pointer(p)), uintptr(n))

The compiler handles a Pointer converted to a uintptr in the argument list of a call to a function implemented in assembly by arranging that the referenced allocated object, if any, is retained and not moved until the call completes, even though from the types alone it would appear that the object is no longer needed during the call.

For the compiler to recognize this pattern, the conversion must appear in the argument list:

 // INVALID: uintptr cannot be stored in variable // before implicit conversion back to Pointer during system call. u := uintptr(unsafe.Pointer(p)) syscall.Syscall(SYS_READ, uintptr(fd), u, uintptr(n))

(Taken from https://golang.org/pkg/unsafe/ )

The way I see it, the only way to be safe is to alloc the memory using C. However, this means we need to copy our data and increases the amount of code which needs to be written by quite a bit.

someObject := (*struct{int; float32})(C.calloc(1, unsafe.Sizeof(struct{int; float32}{}))) // Alloc
*someObject = struct{int; float32}{123, 456.789} // Fill with desired data
someProc.Call(uintptr(unsafe.Pointer(someObject))) // The actual call
C.free(unsafe.Pointer(someObject)) // Clean up

Is there a better way?

Answer 1

I think the correct way to handle this, is to use the mkwinsyscall tool. You can create a Go file like this:

package main
//go:generate mkwinsyscall -output zmsi.go msi.go
//sys MsiOpenDatabase(dbPath string, persist int, db *windows.Handle) (e error) = msi.MsiOpenDatabaseW

Then run go generate , and you get a result file like this (some parts removed for brevity):

func MsiOpenDatabase(dbPath string, persist int, db *windows.Handle) (e error) {
    var _p0 *uint16
    _p0, e = syscall.UTF16PtrFromString(dbPath)
    if e != nil {
        return
    }
    return _MsiOpenDatabase(_p0, persist, db)
}

func _MsiOpenDatabase(dbPath *uint16, persist int, db *windows.Handle) (e error) {
    r0, _, _ := syscall.Syscall(procMsiOpenDatabaseW.Addr(), 3, uintptr(unsafe.Pointer(dbPath)), uintptr(persist), uintptr(unsafe.Pointer(db)))
    if r0 != 0 {
        e = syscall.Errno(r0)
    }
    return
}

As you can see, it automatically takes care of the string conversion, as well as the Syscall code, and even the error handling.