strconv: ParseFloat not working correctly for negative exponent

[Dabada]

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

$ go version
go version go1.13.1 darwin/amd64

Does this issue reproduce with the latest release?

Yes, it does

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

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/moujar/Library/Caches/go-build"
GOENV="/Users/moujar/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/moujar/gitRepos/bdvm"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.13.1/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.13.1/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
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=/var/folders/53/t_01wz8555g4ptmpjz6sy7cr0000gn/T/go-build228600199=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Converting string to float32 with
strconv.ParseFloat

https://play.golang.org/p/8bexC3OjUKs

What did you expect to see?

For a given value less than SmallestNonzeroFloat32 I expect an "value out of range" Error.

What did you see instead?

a result equals to 0 ! And no Error !

[bradfitz]

/cc @griesemer

[griesemer]

This is working as intended.

SmallestNonzeroFloat32 = 1.401298464324817070923729583289916131280e-45. The value 4.940656458412465441765687928682213723651e-123 in your example is much smaller than SmallestNonzeroFloat32/2, in other words, it is correctly rounded down to the next smaller float32 which happens to be 0.0.

Generally, strconv.ParseFloat will return the float32/float64 value closest to the decimal representation - this invariably involves rounding. It looks to me that the rounding here is correct.

There is a big difference with the first example (huge positive exponent): "rounding" fails because the next "larger" float32 after MaxFloat32 is +Inf, and the input clearly is not Inf. Hence it makes sense to report an error.