Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
syscall: mksyscall_windows.go should optionally treat string as UTF16 even if function does not end with W #11807
When creating stubs for Windows DLL routines, mksyscall_windows.go currently maps string parameters to *byte by default and to *uint16 (with UTF-16 conversion) only if the function's name ends in W. There are many Windows routines that take UTF-16 strings but do not end in W. It would be more generally useful if there were a per-syscall or per-parameter option to specify the string width. I'm trying to use mksyscall_windows for a project, and I have to use *uint16 + manual string conversion all over the place because our UTF-16-accepting APIs do not end in W.
(As a side not, it's not clear to me if it's really supported to use mksyscall_windows outside of the go source tree, although there is precedent in some packages on GitHub.)
I'm happy to make the change to mksyscall_windows if someone else will do the bikeshedding for me on how to specify this :). E.g. if I want to import BOOL PathCchIsRoot(PCWSTR), what should I write? The following? Other ideas?
Converting Go string into uint16 is not free. So we're always try to leave it for the caller to decide if that price is worth it.
Also, quite often you have *uint16 field of a struct parameter, rather than *uint16 parameter. You proposal won't handle these.
I don't think it is worth complicating //sys syntax and mksyscall_windows.go code.
But feel free to copy mksyscall_windows.go and change it to your liking. I've done it few times myself.
Use it if it works for you, but be prepared if it breaks your programs and all.
I always use it for my projects - it allows me concentrate on the job rather than spend time making syscalls right. These mistakes can be fatal.
Also mksyscall_windows.go generates GC safe code for syscalls with string parameters (applicable to your case).
Feel free to reopen if I left something out.