Don't require pointer to binding #2834
Conversation
Seems like bumping the golangci version (tektoncd/plumbing#430) revealed some new linting issues. Pointers to items being ranged over are reused, so if this pointer is stored anywhere and used later, it can lead to bugs. I didn't see any reason why this needed to be a pointer so passing around the value instead.
|
This PR cannot be merged: expecting exactly one kind/ label Available
|
1 similar comment
|
This PR cannot be merged: expecting exactly one kind/ label Available
|
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sbwsg The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
This PR cannot be merged: expecting exactly one kind/ label Available
|
ahhh i guess i have to fix these all in one PR or this will always fail - a great case for multiple commits in one PR @vdemeester XD |
I found it a bit hard to understand how to configure this but looking at the example config (https://github.com/golangci/golangci-lint/blob/master/.golangci.example.yml) this seems right. Since we don't control these files, it makes sense to skip linting them. Recently we bumped the linter, which pulled in a new version of gosec, which started flagging "Implicit memory aliasing in for loop" in the generated files. This is a bit weird but at least we know that the values are being used immediately and not stored, so it seems (famous last words) unlikely to hit the bug these are trying to catch (this issue has an example of the kind of bug this catches: https://github.com/trailofbits/gosec/issues/1) e.g. the code getting flagged: ``` for key, val := range *in { var outVal *PipelineRunTaskRunStatus if val == nil { (*out)[key] = nil } else { in, out := &val, &outVal *out = new(PipelineRunTaskRunStatus) (*in).DeepCopyInto(*out) } (*out)[key] = outVal } ```
0779a46 to
ba1aaa6
Compare
Using a pointer here caused us to get the warning "Implicit memory aliasing in for loop" from gosec. Not to mention that functions with side effects are hard to maintain and reason about over time, so instead, we'll now have one function that gets the values to use and we'll actually do the mutation outside the function, so no reason to pass in a pointer.
|
Okay hopefully that was the last of the 3 issues that the linter caught! |
|
The following is the coverage report on the affected files.
|
|
/lgtm |
|
sidecar tests failed 😩 /test pull-tekton-pipeline-integration-tests |
|
/test pull-tekton-pipeline-integration-tests this time it's a different test failing, TestPipelineTaskTimeout So far these are tests that have flaked before (not that im not sad about that!) so im assuming this doesnt have to do with my changes /test pull-tekton-pipeline-integration-tests |
Changes
Seems like bumping the golangci version
(tektoncd/plumbing#430) revealed some new
linting issues.
Pointers to items being ranged over are reused, so if this pointer is
stored anywhere and used later, it can lead to bugs.
I didn't see any reason why this needed to be a pointer so passing
around the value instead.
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
See the contribution guide for more details.
Double check this list of stuff that's easy to miss:
cmddir, please updatethe release Task to build and release this image.
Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.