Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
igalic opened this issue Sep 2, 2021 · 6 comments
Closed

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

igalic opened this issue Sep 2, 2021 · 6 comments
Labels
FrozenDueToAge
Milestone
Unreleased

Comments

@igalic
Copy link

igalic commented Sep 2, 2021

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
@gopherbot gopherbot added this to the Unreleased milestone Sep 2, 2021
@igalic igalic mentioned this issue Sep 2, 2021
Closed
@cherrymui
Copy link
Member

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
Copy link

emaste commented Sep 2, 2021

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
Copy link
Author

igalic commented Sep 2, 2021

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
Copy link
Member

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
Copy link
Contributor

jrtc27 commented Sep 2, 2021 •
edited

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
Copy link
Member

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.

@golang golang locked and limited conversation to collaborators Sep 2, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
5 participants
@igalic @jrtc27 @emaste @gopherbot @cherrymui