Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Integer parameters equal to 2^63 pass the range check in toInt and wrap to a negative number

Open Beginner friendly
  • Is something wrong?
#3,489 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 4 days

@xiao115255 is already working on this.

Since Oct 13, 2026.

  • #3493 by @xiao115255 — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
82/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
go
Domain
backend-api-design

Research direction

Start with toInt in pkg/github/params.go and inspect the existing toInt tests in pkg/github. Run go test ./pkg/github to see the current coverage, then add boundary cases around 2^63 and verify they return the documented range error while valid in-range values still convert.

Written by the indexing model from the issue text.

Description

Describe the bug

toInt in pkg/github/params.go is documented to reject "values outside the int range", but its upper bound check compares against math.MaxInt as a float:

if f > math.MaxInt || f < math.MinInt {
    return 0, fmt.Errorf("numeric value out of int range: %v", f)
}
return int(f), nil

math.MaxInt (2^63 - 1) cannot be represented as a float64 and rounds up to exactly 2^63. A value of 2^63 is therefore not greater than the bound, passes the check, and int(f) on an out-of-range float is implementation-defined in Go. On amd64 it produces math.MinInt (-9223372036854775808).

Any value that parses to 2^63, including the integer 9223372036854775807 itself, is accepted without an error and becomes a large negative number. This affects every tool that reads integers through RequiredInt, OptionalIntParam, OptionalIntParamWithDefault and OptionalPaginationParams (for example issue_number, pull_number, page, perPage). toInt64 is not affected because it uses a round-trip check.

Affected version

main at 07e2466, built from source (Go toolchain from go.mod, linux/amd64).

Steps to reproduce the behavior

  1. Add this test to pkg/github:

    package github

import "testing"

func TestToIntUpperBound(t *testing.T) {
    for _, v := range []any{"9223372036854775807", float64(9223372036854775807), "9223372036854775808", "1e19"} {
        n, err := OptionalIntParam(map[string]any{"pull_number": v}, "pull_number")
        t.Logf("%v -> %d, err=%v", v, n, err)
    }
}

  2. Run go test ./pkg/github -run TestToIntUpperBound -v.

Expected vs actual behavior

Expected: every value at or above 2^63 is rejected with numeric value out of int range, as 1e19 already is.

Actual:

9223372036854775807    -> -9223372036854775808, err=<nil>
9.223372036854776e+18  -> -9223372036854775808, err=<nil>
9223372036854775808    -> -9223372036854775808, err=<nil>
1e19                   -> 0, err=parameter pull_number is not a valid number: numeric value out of int range: 1e+19

The negative value is then sent on to the GitHub API (for example as a pull request number or page) instead of being rejected locally with a clear parameter error.

Logs

Not applicable; the output above is from the test.

Possible Solution
  1. Make the upper bound exclusive at 2^63 (f >= -float64(math.MinInt)), or reuse the round-trip check that toInt64 already performs.
  2. Add the boundary values above to the existing toInt tests.
if f >= -float64(math.MinInt) || f < float64(math.MinInt) {
    return 0, fmt.Errorf("numeric value out of int range: %v", f)
}
return int(f), nil

I'm happy to send a PR.

Dominant language
Go
Stars
33.6k
Forks
5.2k
Avg merge
2d 21h
Merged PRs (30d)
37

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from github/github-mcp-server

All issues in github/github-mcp-server

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.