This seems like a specific case of a general problem, and I'm not sure what the general answer is. There is an awkward mismatch between Go and C when it comes to constant overflow. C silently wraps, Go does not.

Our ad hoc solution is to cast to int64(uint(info.Type)). Getting that cast right is tricky enough to warrant a convenience method, IMHO.

FWIW, I'm unsure if the types for the Type field in the struct (int32/int64) are correct. I don't know how the struct (for Go) is generated, but the manpage for statfs(2) it is advised to use an unsigned int:

The __fsword_t type used for various fields in the statfs structure definition is a glibc internal type, not intended for public use. This leaves the programmer in a bit of a conundrum when trying to copy or compare these fields to local variables in a program. Using unsigned int for such variables suffices on most systems.

The type on amd64 is correct:

#include <sys/vfs.h>
#include <stdio.h>

int main() {
    struct statfs buf;
    printf("%zd\n", sizeof(buf.f_type));
    return 0;
}

prints 8.

What I wanted to point out was that the manpage advises programmers to use an unsigned int, on amd64 in Go Type is of int64. On 386, the type is int32, for which the constant is too big. But it's not too big for an uint32.

Am I missing something?

The type of the f_type field in the C struct statfs is signed. That's why the Go field has a signed type.