-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
cmd/vet: warn about string(int) type conversions #32479
Comments
Pls also permit |
This seems fine to me. The warning should probably point the user in the right direction. |
I think this is essential if this proposal (and eventually #3939) is to be adopted. The |
@networkimprov @alanfo You will still be able to use |
That would be a surprising requirement. And allocates a byte slice for a single statement? |
Well |
I will take a crack at adding an analysis pass and vet check for this. |
Michael Matloob recently presented at a conference the "suggested fixes" feature of the analysis Diagnostics API. The diagnostic for the new analyzer could replace (or offer to replace) the deprecated expressions by the preferred version. |
That could be invalid UTF-8. So To extract strings from buffers, should we generally use |
It could be, but it very much depends on the situation.
I had never even heard of that function until now, and I'm more deliberate than most about string encodings. Slicing a string or byte slice may be perfectly fine, again depending on the situation. |
Be that as it may, it still seems anomalous to allow After all, Indeed, @ianlancetaylor made a similar point in #3939 itself. |
What would be the suggested fix for an integer that overflows the size of the rune? Although this shouldn't occur in practice, simply changing it to
|
Change https://golang.org/cl/212919 mentions this issue: |
@smasher164 Do you have any examples of correct code that has this problem? The correct fix is going to be to add a condition comparing the value to |
@ianlancetaylor Running the tool over my GOPATH revealed 16 cases where an int, uint, int64, or uint64 were converted to a string, and did not do bounds checking to ensure that the converted value doesn't overflow MaxRune. However, most of these cases depend on these functions' call sites, which could potentially be passing only valid input.
|
Thanks for the list. The antlr and ql cases all look like incorrect uses of |
The go-delve case is implementing eval for type conversion, so I would ignore that case. FWIW, if the goal of backwards compatibility in the suggested fixes is to ensure that the fix results in the same string as string(int), then comparing against
When a rune is converted to a string, if bit 22 is set, then the string will print "�". Using this fact, the conversion can be made branchless:
This checks if any of the top 43 bits are nonzero, and uses that truth to set bit 22. |
The goal of the warning is to tell people when their code is not acting as they expect. As far as I can see the fix for cases like antlr is not to add a condition; it's to change the code to use |
That's fair. But we'd have to detect and distinguish those cases from cases where the conversion is correctly made and stays within the bounds of a rune. For instance:
|
golang/go#32479 removed the explicit type conversion string(i) where i has an integer type other than rune in go 1.15. That is a **backward incompatible** change. Fix talent-plan#70.
Symptoms: pkg/gadgets/networkpolicy/networkpolicy.go:143:21: conversion from uint16 to string yields a string of one rune, not a string of digits (did you mean fmt.Sprint(x)?) See: golang/go#32479 Signed-off-by: Alban Crequy <alban@kinvolk.io>
See golang/go#32479 Signed-off-by: Matthew Sykes <sykesmat@us.ibm.com>
See golang/go#32479 Signed-off-by: Matthew Sykes <sykesmat@us.ibm.com>
See golang/go#32479 Fix duosecurity#21. Signed-off-by: Robert-André Mauchin <zebob.m@gmail.com>
testtools/genblocks/main.go:91:74: conversion from int to string yields a string of one rune, not a string of digits (did you mean fmt.Sprint(x)?) golang/go#32479
testtools/genblocks/main.go:91:74: conversion from int to string yields a string of one rune, not a string of digits (did you mean fmt.Sprint(x)?) golang/go#32479
See golang/go#32479 Signed-off-by: Robert-André Mauchin <zebob.m@gmail.com>
See golang/go#32479 Signed-off-by: Robert-André Mauchin <zebob.m@gmail.com>
See golang/go#32479 Signed-off-by: Robert-André Mauchin <zebob.m@gmail.com>
See golang/go#32479 Signed-off-by: Robert-André Mauchin <zebob.m@gmail.com>
#403) Summary: refer to [golang issues](golang/go#32479) Pull Request resolved: #403 Reviewed By: nemith Differential Revision: D29911116 Pulled By: vitaut fbshipit-source-id: 5828d101edb4647834c684453303e27302f1c38a
Symptoms: pkg/gadgets/networkpolicy/networkpolicy.go:143:21: conversion from uint16 to string yields a string of one rune, not a string of digits (did you mean fmt.Sprint(x)?) See: golang/go#32479 Signed-off-by: Alban Crequy <alban@kinvolk.io>
Convert int to string using rune() See golang/go#32479 Fix #384. Signed-off-by: Robert-André Mauchin <zebob.m@gmail.com>
#3939 proposes removing the explicit type conversion
string(i)
wherei
has an integer type other thanrune
. That is a backward incompatible change, so we cannot make it until we can count on having modules everywhere, with the support modules provide for determining the version of the language to use to compile code.There is a step we can take today, which is to change
go vet
to report conversions of integer types other thanrune
tostring
. If we think that removing this feature from the language is a good idea, then a vet check for it is a good idea, and it is one that we can implement today.The text was updated successfully, but these errors were encountered: