x/sys/windows: API break in SecurityAttributes struct

[pete-woods]

What version of Go are you using (go version)?

$ go version
go version go1.11.13 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
N/A

What did you do?

In this revision of x/sys, there was a breaking API change:
golang/sys@5c00192#diff-c4ffa695b270239c949ef5b31be6c4f5

This means that Docker doesn't compile any more:
https://github.com/moby/moby/blob/master/pkg/system/filesys_windows.go#L112

What did you expect to see?

Successful compilation.

What did you see instead?

cannot use uintptr(unsafe.Pointer(&sd[0])) (type uintptr) as type *"golang.org/x/sys/windows".SECURITY_DESCRIPTOR in assignment

[ALTree]

cc @alexbrainman @zx2c4

[zx2c4]

Change is intentional. Going from an unsafe member put there as a stop-gap to a properly typed one now that we have support is sensible. x/sys/windows is unversioned in order to allow for these gradual improvements over time.

Fixed here for moby: moby/moby#40017 --> moby/moby#40021

[ianlancetaylor]

The change is intentional but we don't want to break programs like Docker. Can we keep the old struct and define a new one with a different name?

[ianlancetaylor]

CC @tklauser @bradfitz

[zx2c4]

@ianlancetaylor Then we'd have to change every place that actually uses that struct. The cascading effects aren't pretty.

Meanwhile I've already opened a CL to fix this for Docker and things seem to be moving along nicely there.

[alexbrainman]

I agree with @zx2c4

The change is intentional but we don't want to break programs like Docker.

I though we built modules just for such purpose. Lets see if modules work. I don't use modules myself, so I would not know. But maybe we need to bump module version or something, because it is breaking change. Maybe others will help.

Can we keep the old struct and define a new one with a different name?

We changed SecurityAttributes, and it is used as a parameter in 11 exported functions. Do we duplicate all these API?

We changed from

type SecurityAttributes struct {	
	Length             uint32	
	SecurityDescriptor uintptr	
	InheritHandle      uint32	
}

to

type SecurityAttributes struct {
	Length             uint32
	SecurityDescriptor *SECURITY_DESCRIPTOR
	InheritHandle      uint32
}

When we created original version many years ago, we didn't care about use of SecurityDescriptor field. But now people want to use it.

If we cannot change SecurityAttributes, then people like Jason would have to store code in his private repo, and then others cannot benefit from his efforts.

Alex

[tklauser]

In principle, I'd also prefer a new type being introduced. But since the change was already submitted and we have modules to select a particular revision of the module, I'd also be fine to keep it as is. Also, x/sys/windowsis vendored in the case of moby/docker, so the breakage would only occur after vendoring a new version. This is being done along with the necessary API changes in moby/moby#40021.

People who want the old type could also still use syscall.SecurityAttributes.

[ianlancetaylor]

Modules only help if we tag the sources appropriately, which we aren't doing. And a breaking change requires changing the import path to golang.org/x/sys/windows/v2, which seems undesirable for a minor change like this.

I guess if this is underway we can continue. But let's please pay more attention to breaking changes.