-
Notifications
You must be signed in to change notification settings - Fork 1
Potential fix for code scanning alert no. 271: Incorrect conversion between integer types #28
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
…etween integer types Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
…etween integer types Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
| if value < 0 || value > math.MaxInt64 { // Additional bounds check | ||
| return nil, ErrInvalidSystemVariableValue.New(t.varName, v) // Reject out-of-range values | ||
| } | ||
| intValue := int64(value) |
Check failure
Code scanning / CodeQL
Incorrect conversion between integer types High
strconv.ParseUint
Incorrect conversion of an unsigned 64-bit integer from
strconv.ParseUint
Incorrect conversion of an unsigned 64-bit integer from
strconv.ParseUint
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 5 months ago
The issue can be fixed by explicitly rejecting values that exceed the valid range of int64 when interpreted as signed integers. Additionally, the code can clarify its intent by distinguishing between signed and unsigned conversions, ensuring no ambiguity or misuse occurs.
- Update the
Convertfunction to include more explicit checks forfloat64toint64conversion. - Make the boundary checks explicit and ensure they are tailored to the type being converted (
int64in this case). - Return an appropriate error if the value is out of bounds.
The changes will improve code clarity and ensure that boundary conditions are adequately addressed.
-
Copy modified lines R95-R96
| @@ -92,10 +92,10 @@ | ||
| // Therefore, if the float doesn't have a fractional portion, we treat it as an int. | ||
| if value >= float64(math.MinInt64) && value <= float64(math.MaxInt64) { | ||
| if math.Trunc(value) == value { // Ensure no fractional part exists | ||
| if value < 0 || value > math.MaxInt64 { // Additional bounds check | ||
| intValue := int64(value) | ||
| if intValue < math.MinInt64 || intValue > math.MaxInt64 { // Explicit bounds check | ||
| return nil, ErrInvalidSystemVariableValue.New(t.varName, v) // Reject out-of-range values | ||
| } | ||
| intValue := int64(value) | ||
| return t.SetType.Convert(intValue) | ||
| } | ||
| } |
Potential fix for https://github.com/trimble-oss/go-mysql-server/security/code-scanning/271
To address the issue, the conversion logic must be updated to include explicit bounds checks before performing the type conversion from
float64toint64. This ensures that only values safely within the range ofint64are processed. If the value falls outside this range or has a fractional part that cannot be accurately represented as anint64, an appropriate error should be returned.Steps:
float64value toint64, add upper and lower bound checks specific to theint64type using constantsmath.MinInt64andmath.MaxInt64.Suggested fixes powered by Copilot Autofix. Review carefully before merging.