x/sys/unix: does not define O_LARGEFILE for FreeBSD

[igalic]

What version of Go are you using (go version)?

$ go version
go version go1.17 freebsd/amd64

Does this issue reproduce with the latest release?

yes (this is the latest version)

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/meena/.cache/go-build"
GOENV="/home/meena/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="freebsd"
GOINSECURE=""
GOMODCACHE="/home/meena/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="freebsd"
GOPATH="/home/meena/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/freebsd_amd64"
GOVCS=""
GOVERSION="go1.17"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3854317626=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I tried to use unix.O_LARGEFILE:

package main

import (
	"fmt"
	"golang.org/x/sys/unix"
)

func main() {
	fmt.Println(unix.O_LARGEFILE)
}

What did you expect to see?

meena@76ix ~/s/g/o_largefile> ./o_largefile
0
meena@76ix ~/s/g/o_largefile>

like on the playground: https://play.golang.org/p/9EYN2Wd4xGD

What did you see instead?

meena@beasdix ~/s/g/o_largefile> go get
# eena.me/o_largefile
./o_largefile.go:9:14: undefined: unix.O_LARGEFILE
meena@beasdix ~/s/g/o_largefile [2]> 

in modernc or ccgo there's a work-around in place to define O_LARGEFILE as 0: https://gitlab.com/cznic/libc/-/issues/10

we believe this should be in x/sys/unix

[cherrymui]

FreeBSD doesn't seem to have O_LARGEFILE defined. I don't see O_LARGEFILE in https://www.freebsd.org/cgi/man.cgi?query=open&sektion=2&format=html

[emaste]

Correct, FreeBSD does not have (and does not need) O_LARGEFILE. Software originally written for Linux often wants to set it, so defining it as 0 affords compatibility with such software.

[igalic]

I realise that it doesn't exist.

But it exists on many other Unices, and might just be used by people who expect it to be there, without regard for platforms that have no need for it.

so perhaps it would make sense to just define it 0

if it doesn't make sense, and is better solved in downstream wrappers like modernc, then we can close this issue.

[cherrymui]

I think x/sys/unix is intentionally for OS-dependent stuff. You probably want to use build tags if you use an OS-specific feature.

cc @ianlancetaylor

[jrtc27]

O_LARGEFILE is generally not a good idea on Linux these days anyway. It's meaningless on systems with 64-bit off_t by default, and gated behind _LARGEFILE64_SOURCE in C, though the documentation states that setting _FILE_OFFSET_BITS to 64 instead of using O_LARGEFILE is preferred (but if you're not careful can bite you when it comes to headers that use the non-LFS off_t). So, O_LARGEFILE needs to be phased out, not made more prevalent (and providing a stub definition that's 0 because software can't be bothered to check for Linux before using a Linux-specific define is just a lazy non-solution; somewhat ok in a leaf package, or internal to a library, but not something that should ever be exported by a library that others consume).

[cherrymui]

Thanks. Sounds like we should not add O_LARGEFILE on FreeBSD. Closing.

cc @ianlancetaylor @bradfitz @tklauser . Feel free to chime in if this is mistaken. Thanks.