我有一个使用Unix的go程序，它在使用Capget/Capset时随机崩溃。
感谢@ianlancetaylor,这段代码被识别为罪魁祸首：

hdr := unix.CapUserHeader{Version: unix.LINUX_CAPABILITY_VERSION_3}
var data unix.CapUserData
unix.Capget(&hdr, &data) // this might write past &data.

事实证明，版本2和版本3的Linux功能比版本1的功能更宽。
版本1使用32位字段，完美地适应单个 unix.CapUserData :

type CapUserData struct {
	Effective   uint32
	Permitted   uint32
	Inheritable uint32
}

然而，版本2和版本3的功能是64位，无法适应单个 unix.CapUserData 。
尽管如此，Linux的capget系统调用使用了相同的结构体，但将其写入两个示例的结构体中。它将功能的低位写入第一个结构体，将高位写入第二个结构体。
因此，令人困惑的是，上述代码的正确编写方式应该是：

hdr := unix.CapUserHeader{Version: unix.LINUX_CAPABILITY_VERSION_3}
var data [2]unix.CapUserData
unix.Capget(&hdr, &data[0])

这是C语言中的正常做法，但对我来说看起来不像典型的Go。
这段代码将低位写入 data[0] ,高位写入 data[1] 。然后客户端在设置功能时必须小心，根据功能选择 data[0] 或 data[1] :

data[0].Effective |= 1<<unix.CAP_SYS_ADMIN
data[1].Effective |= 1<<(unix.CAP_CHECKPOINT_RESTORE - 32)

对于unix.Capset也是如此，只是它会读取第一个结构体之外的内容。
我在想，unix.Capget/Capset的签名是否应该更改为类似这样：

func Capget(hdr *CapUserHeader, data *[2]CapUserData) (err error)

以防止类似这样的问题。这样的签名将清楚地表明syscall影响了多少内存。
或者也许在调用过程中扩大字段宽度并重新打包以应对奇怪的内存布局？但这在Linux继续扩展功能并变得更宽的情况下可能不会很好地工作。
大家有什么想法吗？