The breaking change is mentioned in dc6eb20

Breaking API changes in package syscall are:
Mknod takes a uint64 (C dev_t) instead of int.
Stat_t: Dev, Ino, Nlink, Rdev, Gen became uint64.
Atimespec, Mtimespec, Ctimespec, Birthtimespec renamed to Atim, Mtim, Ctim, Birthtim respectively.

I see there was some discussion of this in https://go-review.googlesource.com/c/go/+/138595

If we have to do stuff like this ourselves, I worry how much stuff in the wild will break with this change.

;-)

I made a patch to a8m/tree to see what it looked like to work around this - it turns out it isn't too ugly. Renaming the Ctimespec field to Ctim does at least bring it into line with some of the other unixes, even if it diverges from the other BSDs

diff --git a/csort_bsd.go b/csort_bsd.go
index f5895a6..50a769b 100644
--- a/csort_bsd.go
+++ b/csort_bsd.go
@@ -1,4 +1,4 @@
-//+build darwin freebsd netbsd
+//+build darwin freebsd,!go1.12 netbsd
 
 package tree
 
diff --git a/csort_unix.go b/csort_unix.go
index 6acd092..eead420 100644
--- a/csort_unix.go
+++ b/csort_unix.go
@@ -1,4 +1,4 @@
-//+build linux openbsd dragonfly android solaris
+//+build linux openbsd dragonfly android solaris freebsd,go1.12
 
 package tree
 

These names were introduced more than 8 years ago:
freebsd/freebsd-src@4f08ecd

And the syscall structs are semi-automatically generated from the C headers.

According to the go compatibility promise

It is impossible to guarantee long-term compatibility with operating system interfaces, which are changed by outside parties. The syscall package is therefore outside the purview of the guarantees made here. As of Go version 1.4, the syscall package is frozen. Any evolution of the system call interface must be supported elsewhere, such as in the go.sys subrepository. For details and background, see this document.

I read this as the syscall package is frozen from go 1.4 so backwards incompatible changes should not be introduced unless absolutely necessary.

Personally speaking, I'm easy either way, but I'd like this issue to have a statement from the go team so when go1.12 is released and it breaks people's programs, they will have have some rationale to read.

Cc: @bradfitz since he reviewed the original CL.

It's not actually clear to me why we changed the names of the Ctimespec, Mtimespec, and Atimespec fields. It would make sense to change the names if the types had to change, but comparing 1.11 and tip it seems that the types are the same. Is there any reason not to keep the field names we had all along? It doesn't seem to me that the fact that the fields changed names in FreeBSD is enough to reason to change the fields in the syscall package. That would be a reason to change the field in the golang.org/x/sys/unix package, which is what all new code should be using anyhow.

I'm slightly in favor of renaming them back.

But since some fields are necessarily changing anyway, I didn't fight too much breaking some other fields while we're at it. (People who use syscall are due for some pain in any case.) But we could reduce some of it here.

Change https://golang.org/cl/155958 mentions this issue: syscall: revert to pre-FreeBSD 10 / POSIX-2008 timespec field names in Stat_t on FreeBSD

@ianlancetaylor we were carrying our own hard-coded version of struct stat8, based on the 8-STABLE version since go1.3 (to support FreeBSD 10 I think, discussion).
And since the go1.4 syscall freeze it was kept unmodified.

FreeBSD 12 introduces a struct freebsd11_stat struct for backward compatibility with pre-64bit inode syscalls. it, and the FreeBSD 12 version of struct stat use the new names.

I've sent a CL to rewrite them back using mkpost.go.