-
Notifications
You must be signed in to change notification settings - Fork 18k
cmd/vet: report uses of -0 in float32/64 context #19675
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
Comments
|
@randall77 Good point. -0 is just 0 in any numeric context. It's just that with integer values we understand that -0 and 0 are the same, and so there's not the same expectation as for floats. I suppose one could report it as well. |
cc @robpike How often does this really happen? |
@josharian Probably rather rare, but when it happens and it's not caught, it can be annoying. I believe it should be rather trivial to test for: go/types provides the actual machine-type for such constants, and if it's a float32/64, we just look to see if the constant expression has value 0 and starts with a negation (we may want to exclude complex expressions which be designed to also produce non-0 values if constant values change). |
Please demonstrate the three criteria listed in cmd/vet/README are satisfied. I believe it's hard to satisfy any of them. |
Correctness: An untyped -0 used in floating-point context will always be interpreted as 0 rather than -0, which is probably not what's intended (or otherwise there wouldn't be a minus sign). Missing this detail has caused confusion at best, and bugs at worst. Most recently #19673 exposed the incorrect use of -0 in a test which in turn didn't test all it was supposed to test (and two test cases were incorrect). Precision: This test can be done precisely and cheaply. We know if an expression is constant, we know its value, and we know its type. A constant expression with 0 value used in float context shouldn't have the form -x. Frequency: This is the only critera which may perhaps not be satisfied. The main reason for that is that most people don't do floating point. However, in code dealing with floating-point arithmetic primarily, the use of -0 is not that uncommon. |
I have trouble believing it's a worthwhile addition, but I've made it a proposal so it can be discussed in that category. |
Since the check is cheap, proposal accepted. |
DO NOT REVIEW This is a quick hack for golang#19732. It needs more thought, tests, and docs. Updates golang#19675 Change-Id: Id1a323ba7ec001b2f1a88f30497defc6b823d409
CL https://golang.org/cl/38779 mentions this issue. |
Now that vet runs by default I'd only want to do this if we think it should be run automatically. Leaving for Go 1.11. |
interesting test case (which should not complain): https://play.golang.org/p/uGsLWDfHvqR package main
import (
"fmt"
)
const (
a float64 = -1 * iota
b
c
d
)
func main() {
fmt.Println(a, b, c, d)
} |
dtto simple const (
a = -iota
b
c
) must remain valid even when there's an untyped `-0' in it. |
@nightlyone @cznic the implementation in CL 38779 should handle both of those cases correctly (i.e. not complain). I'm marking this as help wanted. CL 38779 is (I think) a good initial implementation. It mainly needs docs and tests. I hope someone interested will use CL 38779 as a base and build from there. |
This seems like a good starter issue for vet, especially given how there's a sample solution by Josh already. I'll give a shout out about it at the next London meetup, as I think there were a few people eager to contribute to Go last time.
|
New tasks include: golang/go#19675 cmd/vet: report uses of -0 in float32/64 context golang/go#19683 cmd/compile: eliminate usages of global lineno golang/go#19670 x/tools/go/ssa: make opaqueType less annoying to use golang/go#19636 encoding/base64: decoding is slow golang/go#23471 x/perf/cmd/benchstat: tips or quickstart for newcomers golang/go#19577 test: errorcheck support for intraline errors golang/go#19490 cmd/vet: reduce the amount of false positives for -shadow mode golang/go#19042 cmd/internal/obj: optimize wrapper method prologue for branch prediction golang/go#19013 cmd/compile: add tool for understanding/debugging SSA rules
Seems like this is a subset of #30951. Further discussion on the -0 float check should continue there. |
There are no -0 Go constants, -0 is the same as 0. Consequently, using -0 (or -0.0) to set a float32 or float64 variable will not produce the desired effect.
cmd/vet should report the use of a -0 in float32/64 context; i.e., if the type implied by context for a -0 constant is float32 or float64, the code is likely incorrect.
The text was updated successfully, but these errors were encountered: