Improve big-endian testing

[dswarbrick]

Yet another test failure on s390x / big-endian hosts:

$ go test -v -count 1 -run TestNlmsgFprintf ./...
=== RUN   TestNlmsgFprintf
=== RUN   TestNlmsgFprintf/nft_add_table_ip_nat
--- FAIL: TestNlmsgFprintf (0.00s)
    --- FAIL: TestNlmsgFprintf/nft_add_table_ip_nat (0.00s)
panic: runtime error: index out of range [16] with length 16 [recovered, repanicked]

goroutine 9 [running]:
testing.tRunner.func1.2({0x3313e0, 0x4ca41d8b40c0})
        /usr/lib/go-1.26/src/testing/testing.go:1974 +0x238
testing.tRunner.func1()
        /usr/lib/go-1.26/src/testing/testing.go:1977 +0x334
panic({0x3313e0?, 0x4ca41d8b40c0?})
        /usr/lib/go-1.26/src/runtime/panic.go:860 +0x12a
github.com/mdlayher/netlink.nlmsgFprintf({0x369020, 0x4ca41d920ba0}, {{0x28, 0xa00, 0x1, 0x1, 0x4d2}, {0x4ca41d8b4090, 0x14, 0x14}}, ...)
        /home/dswarbrick/netlink/debug_linux.go:176 +0x988
github.com/mdlayher/netlink.TestNlmsgFprintf.func1(0x4ca41d9fe488)
        /home/dswarbrick/netlink/debug_linux_test.go:207 +0x7a
testing.tRunner(0x4ca41d9fe488, 0x4ca41d8ae300)
        /usr/lib/go-1.26/src/testing/testing.go:2036 +0x118
created by testing.(*T).Run in goroutine 8
        /usr/lib/go-1.26/src/testing/testing.go:2101 +0x4f8
FAIL    github.com/mdlayher/netlink     0.004s
testing: warning: no tests to run
PASS
ok      github.com/mdlayher/netlink/nlenc       0.001s [no tests to run]
testing: warning: no tests to run
PASS
ok      github.com/mdlayher/netlink/nltest      0.002s [no tests to run]
FAIL

Test passes as expected on amd64 / little-endian hosts.

[nickgarlis]

Thanks for opening this issue. I've been thinking of introducing a test job emulating big-endian on QEMU so that such issues do not go unnoticed. It’d also be nice to improve big-endian testing in general. I’ll rename and keep this open for any suggestions.

[dswarbrick]

These big-endian test failures frequently pop up on Debian CI tests, since s390x is still a supported architecture. Although I don't think we'll see any new big-endian CPU archs appear, I doubt that s390x is going away anytime soon.

For the record, there are similar test failures in https://github.com/mdlayher/genetlink also, e.g. TestFamily_parseAttributes, for essentially the same reason - endian-specific test fixtures.

[nickgarlis]

Thanks for providing context!

For reference, here is an example of what I had in mind: https://github.com/florianl/go-tc/blob/8fa73f9a1b38f5a099e072305d29539908b748e5/.github/workflows/integration.yml

[dswarbrick]

For reference, here is an example of what I had in mind: https://github.com/florianl/go-tc/blob/8fa73f9a1b38f5a099e072305d29539908b748e5/.github/workflows/integration.yml

That would be very nice, if implemented. You would not believe how often I have to patch 32-bit integer overflows in Debian packages, because the upstream project used untyped ints and did not bother testing with GOARCH="386". Throw big-endian hosts into the mix, and you have a whole new class of bugs.

[dlanov]

I would like to work on this. For a focused first PR, I propose adding an s390x/QEMU CI job and making TestNlmsgFprintf architecture-neutral so its current skipBigEndian guard can be removed. The goal would be to run the existing netlink tests on both little- and big-endian architectures without changing production behavior. Does that scope match what you had in mind?