-
Notifications
You must be signed in to change notification settings - Fork 671
[Chore] Fix lint errors caused by casting int to int32 #2368
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
Conversation
|
|
||
| rayContainer.LivenessProbe = &corev1.Probe{ | ||
| InitialDelaySeconds: utils.DefaultLivenessProbeInitialDelaySeconds, | ||
| TimeoutSeconds: int32(probeTimeout), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The linter is not smart enough to determine whether casting probeTimeout (int) to int32 will cause an overflow, but it can determine if an overflow will occur when casting utils.DefaultLivenessProbeTimeoutSeconds or utils.DefaultHeadLivenessProbeTimeoutSeconds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is not the fault of the linter. Because utils.DefaultLivenessProbeTimeoutSeconds is a constant so the linter can easily find it will not cause error if casted to int32. But for the int32(probeTimeout) case, the linter cannot determine if it will cause an overflow because it does not know whether probeTimeout is assigned with some other values in between.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can check securego/gosec#1212. The gosec community seems to consider it as a false positive because probeTimeout should be either utils.DefaultLivenessProbeTimeoutSeconds or utils.DefaultHeadLivenessProbeTimeoutSeconds which is smaller than MaxInt32 and should not cause overflow when casting.
| worker.NumOfHosts = 1 | ||
| } | ||
| numExpectedPods := workerReplicas * worker.NumOfHosts | ||
| numExpectedPods := int(workerReplicas * worker.NumOfHosts) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Converting int32 to int will not cause overflow. Therefore, I decide to convert int32 to int instead of converting int to int32.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code is doing the opposite, it converts to int instead of int32?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yeah, it is a typo in my comment.
.golangci.yml
Outdated
| gosec: | ||
| excludes: | ||
| - G601 | ||
| # G115 is reporting false positives in golangci-lint v1.60.3. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
G115 is reporting false negatives, and the gosec community still hasn't reached a final conclusion. Therefore, I’ve decided to disable it by default: securego/gosec#1212.
| return errstd.New("numServeEndpoints exceeds math.MaxInt32") | ||
| } | ||
| rayServiceInstance.Status.NumServeEndpoints = int32(numServeEndpoints) //nolint:gosec // Already checked in the previous line. | ||
| rayServiceInstance.Status.NumServeEndpoints = int32(numServeEndpoints) //nolint:gosec // This is a false positive from gosec. See https://github.com/securego/gosec/issues/1212 for more details. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is not a false positive. The type of numServeEndPonits is int, so it may be 32 or 64 bits depending on the system. If it is 64 bits, then casting it to int32 will cause overflow. So this comment should not be changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
numServeEndpoints should be between 0 and MaxInt32, so converting it to int32 should not cause an overflow. Based on securego/gosec#1212, the gosec community considers it as a false positive.
andrewsykim
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
| worker.NumOfHosts = 1 | ||
| } | ||
| numExpectedPods := workerReplicas * worker.NumOfHosts | ||
| numExpectedPods := int(workerReplicas * worker.NumOfHosts) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code is doing the opposite, it converts to int instead of int32?
|
@MortalHappiness I merge this PR for now to unblock other PRs. If my replies don't make sense to you, we can discuss offline and maybe open a follow up PR instead. |
Why are these changes needed?
It may cause overflow when casting
inttoint32, andgolangci-lintrelies ongosec's rule G115 to check it. However, G115 causes some false positives, and thegoseccommunity is still working on the issue: securego/gosec#1212. We should remove//nolintuntil the false positive issue is solved.Open an issue to track the progress: #2369
Related issue number
Checks