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

Comments

Projects
None yet
6 participants
@dsnet
Copy link
Member

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

This comment has been minimized.

Copy link
Member

commented Jan 12, 2017

@dhananjay92

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Contributor

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 Jan 12, 2017

@minux

This comment has been minimized.

Copy link
Member

commented Jan 13, 2017

@dsnet

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link
Member

commented Jan 13, 2017

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.
You can’t perform that action at this time.