TheAlgorithms/Go · error

integer overflow

Error message

integer overflow

What it means

ErrorIntOverflow is the sentinel error returned by Multiply64BitInt when multiplying two int64 values would exceed int64 range (|left| * |right| > MaxInt64). It protects modular exponentiation internals from silent wrap-around.

Source

Thrown at math/modular/exponentiation.go:18

// exponentiation.go
// description: Implementation of Modular Exponentiation Algorithm
// details:
// A simple implementation of Modular Exponentiation - [Modular Exponenetation wiki](https://en.wikipedia.org/wiki/Modular_exponentiation)
// time complexity: O(log(n)) where n is the exponent
// space complexity: O(1)
// author(s) [Taj](https://github.com/tjgurwara99)
// see exponentiation_test.go

package modular

import (
	"errors"
	"math"
)

// ErrorIntOverflow For asserting that the values do not overflow in Int64
var ErrorIntOverflow = errors.New("integer overflow")

// ErrorNegativeExponent for asserting that the exponent we receive is positive
var ErrorNegativeExponent = errors.New("negative Exponent provided")

// Exponentiation returns base^exponent % mod
func Exponentiation(base, exponent, mod int64) (int64, error) {
	if mod == 1 {
		return 0, nil
	}

	if exponent < 0 {
		return -1, ErrorNegativeExponent
	}
	_, err := Multiply64BitInt(mod-1, mod-1)

	if err != nil {
		return -1, err
	}

View on GitHub (pinned to 5ba447ec5f)

Solutions

  1. Reduce operands modulo mod before multiplying (use modular.Multiply via Exponentiation semantics so values stay < mod).
  2. Use math/big (big.Int.Mul / MulMod-style logic) for values approaching MaxInt64.
  3. Check operands before the call: if |a| > MaxInt64/|b| the multiply will overflow.
  4. Handle the error with errors.Is(err, modular.ErrorIntOverflow) and switch to a wider representation.

Example fix

// before
r, err := modular.Multiply64BitInt(math.MaxInt64, 2) // ErrorIntOverflow

// after
bigA, bigB := new(big.Int).SetInt64(a), new(big.Int).SetInt64(b)
r := new(big.Int).Mul(bigA, bigB) // arbitrary precision
Defensive patterns

Strategy: validation

Validate before calling

func safeMul(a, b int64) bool {
    if a == 0 || b == 0 {
        return true
    }
    return math.Abs(float64(a)) <= float64(math.MaxInt64)/math.Abs(float64(b))
}

if !safeMul(left, right) {
    // use big.Int instead
}
r, err := modular.Multiply64BitInt(left, right)

Try / catch

r, err := modular.Multiply64BitInt(left, right)
if errors.Is(err, modular.ErrorIntOverflow) {
    // fall back to big.Int arithmetic
}
if err != nil {
    return 0, err
}

Prevention

When it happens

Trigger: Calling modular.Multiply64BitInt(left, right) with large magnitudes, e.g. Multiply64BitInt(math.MaxInt64, 2), or Exponentiation with a large base/mod whose intermediate products exceed int64.

Common situations: Cryptography/competitive-programming code with moduli near 2^63; using int64 instead of big.Int for very large exponents; float64-based magnitude precheck losing precision near MaxInt64.

Related errors


AI-assisted analysis of TheAlgorithms/Go@5ba447ec5f (2026-09-02). Data as JSON: /api/errors/85d73ff92f516786. Report an issue: GitHub.