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 摘要。