Transcript based unix:rlimits test failing on FreeBSD 13.0 amd64

[krader1961]

            ~> set unix:rlimits[cpu] = [&cur=[]]
            -want +got:
            @@ -1,2 +1,2 @@
            -Exception: bad value: cur in rlimit value must be number between 0 and 18446744073709551615, but is []
            +Exception: bad value: cur in rlimit value must be number between 0 and 9223372036854775807, but is []
               [tty]:1:5-21: set unix:rlimits[cpu] = [&cur=[]]
        test_transcript.go:118:
            ~> set unix:rlimits[cpu] = [&cur=1 &max=[]]
            -want +got:
            @@ -1,2 +1,2 @@
            -Exception: bad value: max in rlimit value must be number between 0 and 18446744073709551615, but is []
            +Exception: bad value: max in rlimit value must be number between 0 and 9223372036854775807, but is []
               [tty]:1:5-21: set unix:rlimits[cpu] = [&cur=1 &max=[]]
FAIL
FAIL    src.elv.sh/pkg/mods/unix        1.421s

The issue here seems to be that FreeBSD uses uint64 while other platforms use int64. Note that I get the same exception on FreeBSD prior to the recent change that introduced transcript based unit tests. The decimal value 9223372036854775807 is 0x7FFFFFFFFFFFFFFF. Which matches the definition of infinity on FreeBSD:

#define RLIM_INFINITY   ((rlim_t)(((__uint64_t)1 << 63) - 1))

Note that decimal 18446744073709551615 (the expected value) is 0xFFFFFFFFFFFFFFFF which is -1, the usual value for infinity on platforms (which is most of them) that use a signed int for these values. The old tests relied on pkg/mods/unix/rlim_t_int64.go and /pkg/modes/unix/rlim_t_uint64.go to finesse the type difference between FreeBSD and all other Unix platforms.

[krader1961]

What is perplexing is why the existing FreeBSD CI environment doesn't catch this problem. Before fixing this so the test passes on my VM we should probably figure out why the existing FreeBSD CI environment didn't catch the problem.

[xiaq]

It seems that a bug in Go has prevented the tests from actually running. I reported https://github.com/golang/go/issues/65425.