Increase unit test coverage of strconv/itoa.go from 83.8% to 85%
Change-Id: I0abdfc70a3f06251106f229c12ffb105eeb43fc8
GitHub-Last-Rev: da9755368b
GitHub-Pull-Request: golang/go#55014
Reviewed-on: https://go-review.googlesource.com/c/go/+/430137
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Jenny Rakoczy <jenny@golang.org>
Reviewed-by: Jenny Rakoczy <jenny@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Jenny Rakoczy <jenny@golang.org>
Change-Id: I25c8e8b701d6489f360fea30d09090826276b950
GitHub-Last-Rev: c2c8319dd5
GitHub-Pull-Request: golang/go#54924
Reviewed-on: https://go-review.googlesource.com/c/go/+/428976
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
When one has a []byte on hand, but desires to call the Parse functions,
the conversion from []byte to string would allocate.
var b []byte = ...
v, err := strconv.ParseXXX(string(b), ...)
This changes it such that the input string never escapes from
any of the Parse functions. Together with the compiler optimization
where the compiler stack allocates any string smaller than 32B
this makes most valid inputs for strconv.ParseXXX(string(b), ...)
not require an allocation for the input string.
For example, the longest int64 or uint64 encoded in decimal is 20B.
Also, the longest decimal formatting of a float64 in appendix B
of RFC 8785 is 25B.
Previously, this was not possible since the input leaked to the error,
which causes the prover to give up and instead heap copy the []byte.
We fix this by copying the input string in the error case.
The advantage of this change is that you can now call strconv.ParseXXX
with a []byte without allocations (most times) in the non-error case.
The detriment is that the error-case now has an extra allocation.
We should optimize for the non-error path, rather than the error path.
The effects of this change is transitively seen through packages
that must use strconv.ParseXXX on a []byte such as "encoding/json":
name old time/op new time/op delta
UnmarshalFloat64 186ns 157ns -15.89% (p=0.000 n=10+10)
name old alloc/op new alloc/op delta
UnmarshalFloat64 148B 144B -2.70% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
UnmarshalFloat64 2.00 1.00 -50.00% (p=0.000 n=10+10)
In order for "encoding/json" to benefit, there needs to be a
small change made to how "encoding/json" calls strconv.ParseXXX.
That will be a future change.
Credit goes to Jeff Wendling for a similar patch.
Fixes#42429
Change-Id: I512d6927f965f82e95bd7ec14a28a587f23b7203
Reviewed-on: https://go-review.googlesource.com/c/go/+/345488
Reviewed-by: Martin Möhrmann <martin@golang.org>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Calling FormatFloat with an invalid value of fmt is expected
to return a string containing '%' and the input fmt character.
Since even before Go 1.0, the code has been panicking in the
case where prec=0.
Fixes#52187
Change-Id: I74fec601eedb7fe28efc5132c4253674661452aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/402817
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Emmanuel Odeke <emmanuel@orijtech.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
strings for 'NaN' -> string for 'NaN'
Change-Id: Ia415644a1b651e6ef9996ad24dd9708a60e57dfc
GitHub-Last-Rev: 877f1c3eb1
GitHub-Pull-Request: golang/go#53246
Reviewed-on: https://go-review.googlesource.com/c/go/+/410494
Auto-Submit: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The documentation for strconv.ParseFloat mentions that it "accepts
decimal and hexadecimal floating-point number syntax", but it doesn't
specify what those formats entail. For example, "0x10" is not allowed;
you need an explicit exponent, as in "0x10p0".
This clarifies that ParseFloat accepts the Go syntax for floating-point
literals, and links to that spec section. I've also linked to the
relevant spec section for ParseInt's doc comment, which already said
"as defined by the Go syntax for integer literals".
Change-Id: Ib5d2b408bdd01ea0b9f69381a9dbe858f6d1d424
Reviewed-on: https://go-review.googlesource.com/c/go/+/410335
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
[This CL is part of a sequence implementing the proposal #51082.
The design doc is at https://go.dev/s/godocfmt-design.]
Run the updated gofmt, which reformats doc comments,
on the main repository. Vendored files are excluded.
For #51082.
Change-Id: I7332f099b60f716295fb34719c98c04eb1a85407
Reviewed-on: https://go-review.googlesource.com/c/go/+/384268
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
A future change to gofmt will rewrite
// Doc comment.
//
func f()
to
// Doc comment.
func f()
Apply that change preemptively to all doc comments.
For #51082.
Change-Id: I4023e16cfb0729b64a8590f071cd92f17343081d
Reviewed-on: https://go-review.googlesource.com/c/go/+/384259
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
\u007f is not wrong but it's weird to use \u when we could use the
shorter \x.
Fixes#52062
Change-Id: Ica4bdc2463128051876f44e15297ed1e9edf1de8
Reviewed-on: https://go-review.googlesource.com/c/go/+/397255
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Many uses of Index/IndexByte/IndexRune/Split/SplitN
can be written more clearly using the new Cut functions.
Do that. Also rewrite to other functions if that's clearer.
For #46336.
Change-Id: I68d024716ace41a57a8bf74455c62279bde0f448
Reviewed-on: https://go-review.googlesource.com/c/go/+/351711
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Unquote implements unescaping a "single-quoted, doubled-quoted, or
backquoted Go string literal". Therefore, it should reject anything
that the Go specification explicitly forbids.
The section on "Rune literals" explicitly rejects rune values
"above 0x10FFFF and surrogate halves". We properly checked for
the previous condition, but were failing to check for the latter.
In general, "r > utf8.MaxRune" is probably the wrong check,
while !utf8.ValidRune(r) is the more correct check.
We make changes to both UnquoteChar and appendEscapedRune
to use the correct check. The change to appendEscapedRune
is technically a noop since callers of that function already
guarantee that the provided rune is valid.
Fixes#47853
Change-Id: Ib8977e56b91943ec8ada821b8d217b5e9a66f950
Reviewed-on: https://go-review.googlesource.com/c/go/+/343877
Trust: Joe Tsai <joetsai@digital-static.net>
Run-TryBot: Joe Tsai <joetsai@digital-static.net>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Explicitly document the handling of a sign prefix, and the interaction
between the sign and base prefixes.
Fixes#46641.
Change-Id: I3cd6773e3f074fe671a944a05a79d2408137fcd4
Reviewed-on: https://go-review.googlesource.com/c/go/+/325875
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Previously we would sometimes return ErrRange if the parseable part of
the floating point number was out of range.
Fixes#46628
Change-Id: I15bbbb1e2a56fa27c19fe25ab5554d988cbfd9d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/325750
Trust: Ian Lance Taylor <iant@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
QuotedPrefix is similar to Unquote, but returns the quoted string verbatim
and ignores any data after the quoted string.
Fixes#45033
Change-Id: I9f69fe9e3e45cbe9e63581cf1b457facb625045d
Reviewed-on: https://go-review.googlesource.com/c/go/+/314775
Trust: Joe Tsai <joetsai@digital-static.net>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
On my machine (3.1 GHz Quad-Core Intel Core i7, macOS 10.15.7 10.15.7), go 1.15.6
benchstat:
name old time/op new time/op delta
SearchInts-8 20.3ns ± 1% 16.6ns ± 6% -18.37% (p=0.000 n=9+10)
Change-Id: I346e5955fd6df6ce10254b22267dbc8d5a2b16c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/279439
Reviewed-by: Ben Shi <powerman1st@163.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Make all our package sources use Go 1.17 gofmt format
(adding //go:build lines).
Part of //go:build change (#41184).
See https://golang.org/design/draft-gobuild
Change-Id: Ia0534360e4957e58cd9a18429c39d0e32a6addb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/294430
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
As part of #42026, these helpers from io/ioutil were moved to os.
(ioutil.TempFile and TempDir became os.CreateTemp and MkdirTemp.)
Update the Go tree to use the preferred names.
As usual, code compiled with the Go 1.4 bootstrap toolchain
and code vendored from other sources is excluded.
ReadDir changes are in a separate CL, because they are not a
simple search and replace.
For #42026.
Change-Id: If318df0216d57e95ea0c4093b89f65e5b0ababb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/266365
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
go/constant relies on strconv for parsing Go literals, while older
versions of strconv either lack recent Go language features (e.g., Go
1.13's new numeric literals) or have errors (e.g., mishandling of
carriage returns in raw string literals prior to Go 1.8).
This requires two changes:
1. Splitting out the internal/bytealg dependency into a separate file,
which can be easily substituted with a simple loop for bootstrap
builds.
2. Updating eisel_lemire.go to not utilize Go 1.13 functionality
(underscores in numeric literals and signed shift counts).
Change-Id: Ib48a858a03b155eebdcd08d577aec2254337e70e
Reviewed-on: https://go-review.googlesource.com/c/go/+/272749
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
This is a partial revert of https://go-review.googlesource.com/c/go/+/248219
because we found that a non-trivial amount of code erroneously calls
ParseFloat(s, 10) or even ParseFloat(s, 0) and expects it to work --
before that change was merged, ParseFloat accepted a bitSize of
anything other than 32 or 64 to mean 64 (and ParseComplex was similar).
So revert that behavior to avoid breaking people's code, and add tests
for this.
I may add a vet check to flag ParseFloat(s, not_32_or_64) in a later
change.
See #42297 for more details.
Change-Id: I4bc0156bd74f67a39d5561b6e5fde3f2d20bd622
Reviewed-on: https://go-review.googlesource.com/c/go/+/267319
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In ParseComplex, the "size" passed to parseFloatPrefix should be 64 for
complex128, not 128. It still works because of how parseFloatPrefix
is forgiving about the size if it's not 32, but worth fixing anyway.
Make ParseComplex and ParseFloat return a bit size error for anything
other than 128 or 64 (for ParseComplex), or 64 or 32 (for ParseFloat).
Add "InvalidBitSize" tests for these cases.
Add tests for ParseComplex with bitSize==64: this is done in a similar
way to how the ParseFloat 32-bit tests work, re-using the tests for the
larger bit size.
Add tests for FormatComplex -- there were none before.
Fixes#40706
Change-Id: I16ddd546e5237207cc3b8c2181dd708eca42b04f
Reviewed-on: https://go-review.googlesource.com/c/go/+/248219
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Minux Ma <minux@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
In many cases, it is not necessary to parse long
decimal mantissas entirely to produce the correctly
rounded floating-point number. It is enough to parse
the short, rounded lower and upper bounds and in most cases
they round to the same floating point number because uint64
can hold 19 digits.
Previously this case was handled by the extFloat code path
(Grisu3 algorithm).
name old time/op new time/op delta
Atof64Big-4 1.07µs ± 2% 0.11µs ± 2% -89.61% (p=0.000 n=10+9)
Atof64RandomLongFloats-4 8.03µs ± 2% 0.14µs ± 7% -98.24% (p=0.000 n=10+10)
Atof32RandomLong-4 760ns ± 1% 156ns ± 0% -79.46% (p=0.000 n=10+8)
Benchmarks versus extFloat:
name old time/op new time/op delta
Atof64Big-4 121ns ± 3% 111ns ± 2% -7.93% (p=0.000 n=10+9)
Atof64RandomLongFloats-4 144ns ± 1% 142ns ± 7% ~ (p=0.167 n=10+10)
Atof32RandomLong-4 129ns ± 1% 156ns ± 0% +21.12% (p=0.000 n=10+8)
Change-Id: Id734b8c11e74b49a444fda67ee72870ae9422e60
Reviewed-on: https://go-review.googlesource.com/c/go/+/264677
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
This is somewhat academic (and no tests failed before this commit),
since func atof64 only calls func eiselLemire when func atof64exact
fails, and func atof64exact doesn't fail when parsing positive or
negative zeroes. But it's still worth fixing.
Change-Id: Ibe6ef4c8fd96827673b711d5456003fbc447e39c
Reviewed-on: https://go-review.googlesource.com/c/go/+/264140
Trust: Nigel Tao <nigeltao@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Also fix BenchmarkAtof64Random* to initialize the test data when none
of the TestAtof* tests are run.
Passing "go test -test.count=5 -test.run=xxx -test.bench=Atof64" on to
benchstat:
name old time/op new time/op delta
Atof64Decimal-4 47.9ns ± 0% 48.3ns ± 1% ~ (p=0.238 n=4+5)
Atof64Float-4 58.3ns ± 3% 57.7ns ± 0% ~ (p=0.151 n=5+5)
Atof64FloatExp-4 107ns ± 0% 71ns ± 1% -33.89% (p=0.016 n=4+5)
Atof64Big-4 163ns ± 0% 166ns ± 2% ~ (p=0.159 n=4+5)
Atof64RandomBits-4 299ns ± 1% 166ns ± 1% -44.41% (p=0.008 n=5+5)
Atof64RandomFloats-4 188ns ± 1% 144ns ± 0% -23.03% (p=0.008 n=5+5)
The canada.json file from github.com/miloyip/nativejson-benchmark is
full of geospatial coordinates (i.e. numbers). With this program:
src, _ := ioutil.ReadFile("canada.json")
for i := 0; i < 5; i++ {
now := time.Now()
for j := 0; j < 10; j++ {
dst := interface{}(nil)
if err := json.Unmarshal(src, &dst); err != nil {
log.Fatal(err)
}
}
fmt.Println(time.Since(now))
}
Median of the 5 printed numbers, lower is better.
Before: 760.819549ms
After: 702.651646ms
Ratio: 1.08x
The new detailedPowersOfTen table weighs in at 596 * 16 = 9536 bytes,
but some of that weight gain can be clawed back, in a follow-up commit,
that folds in the existing powersOfTen table in extfloat.go.
RELNOTE=yes
Change-Id: I3953110deaa1f5f6941e88e8417c4665b649ed80
Reviewed-on: https://go-review.googlesource.com/c/go/+/260858
Run-TryBot: Nigel Tao <nigeltao@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Nigel Tao <nigeltao@golang.org>
The recently added function parseFloatPrefix tested the entire
string for correct placement of separators rather than just the
consumed part. The 4-char fix is in readFloat (atof.go:303).
Added more tests. Also added some white space for nicer
grouping of the test cases.
While at it, removed the need for calling testing.Run.
Fixes#38962.
Change-Id: Ifce84f362bb4ede559103f8d535556d3de9325f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/233017
Reviewed-by: Ian Lance Taylor <iant@golang.org>
parseFloatPrefix accepts a string if it has a valid floating-point
number as prefix. Make sure that "infi", "infin", ... etc. are
accepted as valid numbers "inf" with suffix "i", "in", etc. This
is important for parsing complex numbers such as "0+infi".
This change does not affect the correctness of ParseFloat because
ParseFloat rejects strings that contain a suffix after a valid
floating-point number.
Updates #36771.
Change-Id: Ie1693a8ca2f8edf07b57688e0b35751b7100d39d
Reviewed-on: https://go-review.googlesource.com/c/go/+/231237
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
IntSize is an untyped constant that does not need explicit conversion.
Annotating IntSize as an int and running github.com/mdempsky/unconvert
reveals these two cases.
Fixes#38682.
Change-Id: I014646b7457ddcde32474810153229dcf0c269c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/230306
Run-TryBot: Akhil Indurti <aindurti@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Instead use string(r) where r has type rune.
This is in preparation for a vet warning for string(i).
Updates #32479
Change-Id: Ic205269bba1bd41723950219ecfb67ce17a7aa79
Reviewed-on: https://go-review.googlesource.com/c/go/+/220844
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Akhil Indurti <aindurti@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Toshihiro Shiino <shiino.toshihiro@gmail.com>
Apply the suggestions made in the too-late review of
golang.org/cl/137215
to move the comments to a separate line and use proper
punctuation.
Change-Id: If2b4e5ce8af8c78fa51280d5c87c852a76dae459
Reviewed-on: https://go-review.googlesource.com/c/go/+/206125
Reviewed-by: Robert Griesemer <gri@golang.org>
This does not include an upgrade of golang.org/x/net.
This is optional and best done as a separate CL.
Change-Id: Ifecc3fb6e3b7fe026b4ddefbe637186a3445b0bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/204658
Run-TryBot: Marcel van Lohuizen <mpvl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Updates #30322
This change adds the Unwrap method to NumError. NumError is the only custom error type of the strconv that has a nested exported error.
Change-Id: I8774886348880365a83f72a1d106276def27dffe
GitHub-Last-Rev: 712f3df884
GitHub-Pull-Request: golang/go#34213
Reviewed-on: https://go-review.googlesource.com/c/go/+/194563
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
In addition to the example that was added in 203b80ab, mention these
special cases in the doc comment. This change also adjusts the example
to include "+Inf", as it was not otherwise mentioned that the plus
symbol may be present.
Fix#30990
Change-Id: I97d66f4aff6a17a6ccc0ee2e7f32e39ae91ae454
Reviewed-on: https://go-review.googlesource.com/c/go/+/179738
Reviewed-by: Alex Miasoedov <msoedov@gmail.com>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Run-TryBot: Benny Siegert <bsiegert@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Float formatting uses a multiprecision fallback path where Grisu3
algorithm fails. This has a bug during the rounding phase: the
difference between the decimal value and the upper bound is examined
byte-by-byte and doesn't properly handle the case where the first
divergence has a difference of 1.
For instance (using an example from #29491), for the number
498484681984085570, roundShortest examines the three decimal values:
lower: 498484681984085536
d: 498484681984085568
upper: 498484681984085600
After examining the 16th digit, we know that rounding d up will fall
within the bounds unless all remaining digits of d are 9 and all
remaining digits of upper are 0:
d: ...855xx
upper: ...856xx
However, the loop forgets that d and upper have already diverged and
then on the next iteration sees that the 17th digit of d is actually
lower than the 17th digit of upper and decides that we still can't round
up:
d: ...8556x
upper: ...8560x
Thus the original value is incorrectly rounded down to
498484681984085560 instead of the closer (and equally short)
498484681984085570.
Thanks to Brian Kessler for diagnosing this bug.
Fix it by remembering when we've seen divergence in previous digits.
This CL also fixes another bug in the same loop: for some inputs, the
decimal value d or the lower bound may have fewer digits than the upper
bound, yet the iteration through the digits starts at i=0 for each of
them. For instance, given the float64 value 1e23, we have
d: 99999999999999991611392
upper: 100000000000000000000000
but the loop starts by comparing '9' to '1' rather than '0' to '1'.
I haven't found any cases where this second bug causes incorrect output
because when the digit comparison fails on the first loop iteration the
upper bound always has more nonzero digits (i.e., the expression
'i+1 < upper.nd' is always true).
Fixes#29491
Change-Id: I58856a7a2e47935ec2f233d9f717ef15c78bb2d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/157697
Run-TryBot: Caleb Spare <cespare@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rémy Oudompheng <remyoudompheng@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
cui fliter
Joe Tsai
Rémy Oudompheng
90364136+butterfly1924@users.noreply.github.com
Ben Hoyt
Russ Cox
Ian Lance Taylor
Yasuhiro Matsumoto
Damien Neil
EndlessCheng
yangwenmai
Alexander Rakoczy
Matthew Dempsky
Nigel Tao
Marcel van Lohuizen
Robert Griesemer
pj
smasher164
Rob Pike
Pantelis Sampaziotis
Sam Arnold
Emmanuel T Odeke
Andrew Gerrand
Caleb Spare