Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

syscall: mksyscall_windows.go should optionally treat string as UTF16 even if function does not end with W #11807

Closed
jstarks opened this issue Jul 21, 2015 · 1 comment

Comments

@jstarks
Copy link

@jstarks jstarks commented Jul 21, 2015

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?

//sys PathCchIsRoot(p string [utf16]) (r bool)

@alexbrainman

@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Jul 21, 2015
@alexbrainman
Copy link
Member

@alexbrainman alexbrainman commented Jul 22, 2015

... 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.

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.

... (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.)

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.

Alex

@mikioh mikioh changed the title mksyscall_windows.go should optionally treat string as UTF16 even if function does not end with W syscall: mksyscall_windows.go should optionally treat string as UTF16 even if function does not end with W Jul 23, 2015
@golang golang locked and limited conversation to collaborators Aug 5, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.