cilium
bpf2go: __int128 is converted into invalid uint128 Go type
Describe the bug
When using c unsigned __int128 saddr; in ebpf, it was escaping golang's uint128 which was obviously incorrect, so added to convert it to [16]byte or [16]uint8 instead .... may be slove this issue
There is an open proposal for Go to support types like uint128 in https://github.com/golang/go/issues/9455.
But so far native Go doesn't support uint128.
Was an external package used that tries to implement Go support for uint128?
I've tried using "num" and it seems to solve the problem, but should we refer to this code to implement it
Not the most ergonomic solution, but I think we should emit [16]byte instead of forcing a specific dependency. Users can add a getter to the generated type that calls a constructor for their favourite package.
I think it might be a bit overwhelming to just throw "[16]byte" at the user.
So we should refer to the calculation of "int128" and "uint128". Implement the solution "type uint128 [16]byte". Is that right?
Implement the solution "type uint128 [16]byte". Is that right?
That creates complications, because there might be multiple bpf2go generated files in the same package. With the naive approach you end up with multiple type uint128. I'd skip the type, but you can add a comment to the generated output like in https://github.com/cilium/ebpf/blob/2ca994b15145cd3529a39cea90c7db4b3a7c3b89/btf/format.go#L197
Final output:
type foo struct {
big [16]byte /* uint128 */
}