Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭 适合新手
  • 哪里不对？
#3,489 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 4 天内回复

还没有人认领这个 Issue。

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
82/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
go
领域
backend-api-design

调研方向

从 pkg/github/params.go 中的 toInt 开始，并检查 pkg/github 中现有的 toInt 测试。运行 go test ./pkg/github 查看当前覆盖情况，然后添加 2^63 附近的边界用例。验证这些用例会返回文档所述的范围错误，同时范围内的有效值仍能转换。

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
Go
星标
33.4k
派生
5.1k
平均合并
2 天 10 小时
30 天内合并 PR
35

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

github/github-mcp-server 的其他 Issue

查看 github/github-mcp-server 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。