x/sys/windows: mkwinsyscall: Support - and . in DLL name
#57913
Comments
|
I don't think this has to be a proposal but a bug fix: @dagood can you create a separate bug issue that focus on improving the diagnostics of failing |
qmuntal
changed the title
- and . in DLL name- and . in DLL name
qmuntal
added
help wanted
NeedsFix
dagood
changed the title
- and . in DLL name- and . in DLL name
|
I'm planning to submit a CL soon to escape by changing |
|
@dagood thanks for creating this issue
Can this function be used from Go programs?
Same question. Is it possible to use
So far no one complained about using Otherwise it is fine to make that change. If changes are simple enough. You can also make your own copy of Alex |
|
Change https://go.dev/cl/463215 mentions this issue: |
I got the signature wrong earlier, it should be: //sys SetSocketMediaStreamingMode(value BOOL) (r HRESULT) = windows.networking.SetSocketMediaStreamingMode
type BOOL int32
type HRESULT int32With that, I'm able to call it with
Yep, this works, and the result shows up in I don't have any concrete reasons why either of these would be needed by a Go program. They do seem fairly niche, and I can see why they haven't (and maybe wouldn't have) ever come up. This is just for completeness--it might make more sense to fork/integrate the generator rather than reuse it when #43838 gets further along. I think it's a simple change--just submitted the CL. |
Let's say I wanted to add this API to
x/sys/windows: https://learn.microsoft.com/en-us/windows/win32/api/socketapi/nf-socketapi-setsocketmediastreamingmode. My initial thought is to add something like this//sysline://sys SetSocketMediaStreamingMode(value bool) (err error) = windows.networking.SetSocketMediaStreamingModeHowever,
go generate ./windows/then fails:This is because
mkwinsyscalldoesn't handle more than one., andwindows.networking.SetSocketMediaStreamingModehas two: https://github.com/golang/sys/blob/6e4d1c53cf3b2c1c6d104466749f76cc7a5c9ed8/windows/mkwinsyscall/mkwinsyscall.go#L483-L491-doesn't break in quite the same way, but the fix is related. For example,api-ms-win-wsl-api-l1-1-0.WslRegisterDistributionisn't rejected bymkwinsyscallitself, but the generated code isn't valid because an identifier can't contain a-.Changes
defaultcase to support this by assuming any extra.segments are part of the DLL name. This seems like a valid assumption because the win32 methods won't have.in them..somkwinsyscallgenerates buildable Go code.-work, too, it can also be escaped..and-with_.Effect on
//syslines being (almost entirely) readable Go codeIn that line,
= advapi32.CryptAcquireContextWlets us think of this as aliasing a func in aadvapi32Go package.The proposal breaks the metaphor:
= windows.networking.SetSocketMediaStreamingModeis not valid Go. Is this ok, or doesmkwinsyscallneed to strictly enforce the metaphor?An alternative would be extending the metaphor by importing a "package" with a rename, but this would be more complicated to implement properly:
Background
I'm trying to use
mkwinsyscallfor x/sys/windows: use win32metadata? #43838 by having a generator create//syscomments. When I generated//syslines for all the API methods forWindows.Win32.winmd, I hit these.and-cases.I don't know if it makes sense for #43838 to end up using
mkwinsyscallin this way, but I figure until that proposal gets traction one way or another, it's worth asking about adding this kind of support.format.Sourcefails #57925 for an improvement to diagnosability I made while looking into this issue.The text was updated successfully, but these errors were encountered: