-
Notifications
You must be signed in to change notification settings - Fork 7
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
fix: golangci-lint warnings about unsafe integer conversions #882
fix: golangci-lint warnings about unsafe integer conversions #882
Conversation
gosec 115 has been promoted into golangci-lint v1.60.2. That's about integer conversion. We're doing nasting conversions there: uintptr -> int (we're 64-bit, but still bad for portable type-safe code) uintptr -> uint32 (we relied on domain knowledge the compiler cannot ensure). This reimplements the low-level byte-counting to: - Merge two functions into one, reducing the risk of mistakes - Doing all the math with uint64 and - Finally validate that the amount we'd allocate is still <= MaxUint32. This way we don't surface the int conversions, but rather keep them isolated into a single function.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## dependabot/go_modules/tools/github.com/golangci/golangci-lint-1.60.2 #882 +/- ##
========================================================================================================
+ Coverage 88.61% 88.87% +0.25%
========================================================================================================
Files 105 105
Lines 6806 6821 +15
========================================================================================================
+ Hits 6031 6062 +31
+ Misses 600 584 -16
Partials 175 175 ☔ View full report in Codecov by Sentry. |
6ff64e1
to
8d1cdd8
Compare
With one way that demonstrates we don't overflow uint32
It's too much close to the real system APIs :)
To prevent false warnings of narrow conversion from uintptr. StoreApiError aliased to int64 instead of int
e0efdbd
to
174bee4
Compare
There is some non-negligible error translation in there mostly due the somewhat involving error handling imposed by syscall/dll_windows. This adds a modest set of test cases to cover that logic. For that to be approachable I extracted the error reporting out of the proc call method, this way we don't depend on calling a DLL function to test this part. Quite artificial setup, but I always enjoy separating "computing" from "doing".
174bee4
to
c250e5c
Compare
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.
Looks great! I’m trusting you on the Win32 API returned values.
However, I have a couple of nitpicks and one question/remark on the growing size for the adapter address logic!
All about the semantics of calling a dll Proc.
At the expense of repeating the error handling.
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.
Thanks for addressing those!
6afb8c3
into
dependabot/go_modules/tools/github.com/golangci/golangci-lint-1.60.2
Most of the warnings were not a real issue, but the one around the Win32 GetAdapterAddersses was harder to prove with the previous implementation so I refactored it a little bit to make it easy to reach the piece of mind that we're not doing nasting error-prone narrowing conversions.
This should unblock #877 .
UDENG-4234