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

cmd/vet: warn when iterating over an array #18626

Closed
dsnet opened this issue Jan 12, 2017 · 6 comments
Closed

cmd/vet: warn when iterating over an array #18626

dsnet opened this issue Jan 12, 2017 · 6 comments

Comments

@dsnet
Copy link
Member

dsnet commented Jan 12, 2017

See #18625 for an interesting bug where large stack growth was caused by this. To avoid false positives, maybe vet should only warn if the array size exceeds some number of bytes?

\cc @robpike @dominikh @minux

@minux
Copy link
Member

minux commented Jan 12, 2017 via email

@JayNakrani
Copy link
Contributor

JayNakrani commented Jan 12, 2017

... maybe vet should only warn if the array size exceeds some number of bytes?

Just out of curiosity, how can vet statically determine the size of an array? Never mind. Just saw that the arrays in question have fixed length.

@robpike
Copy link
Contributor

robpike commented Jan 12, 2017

It is correct to do so, and can even be the right thing to do in many cases. It's therefore not something that vet can complain about. (See the src/cmd/vet/README for details.)

Perhaps golint is a better choice. Feel free to suggest that.

@robpike robpike closed this as completed Jan 12, 2017
@minux
Copy link
Member

minux commented Jan 13, 2017 via email

@dsnet
Copy link
Member Author

dsnet commented Jan 13, 2017

It's not obvious to me that this is a style issue. Even if it were, for k, v := range array (the "wrong" one) certainly looks nicer and less surprising than for k, v := range array[:] (the "right" one).

However, I can see why this doesn't quite fit vet either, since use of it still produces a correct program. I'm starting to see a significant number of issues that don't quite fit vet (focus on correctness), and doesn't fit lint (focus on style)... there seems to be a number of checks proposed that catch problems that aren't strictly wrong, but heavily suspicious, this being an example of one. Maybe these checks should go into a third-party tool like go-staticcheck?

@dominikh
Copy link
Member

I don't think it's a fit for any of my tools, either, for essentially the same reason as for why it shouldn't go into vet.

@golang golang locked and limited conversation to collaborators Jan 13, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants