What causes "size too big in '{}'" in BurntSushi/ripgrep?

Lower the numeric portion so the scaled result fits in u64.

BurntSushi/ripgrep · error · ParseSizeError

size too big in '{}'

Error message

size too big in '{}'

What it means

parse_human_readable_size returns ParseSizeErrorKind::Overflow when the suffix multiplication (checked_mul by 1<<10/1<<20/1<<30) wraps past u64::MAX. Unlike InvalidInt, the digit portion itself parsed fine; only the scaled result is too large.

Source

Thrown at crates/cli/src/human.rs:60

impl std::fmt::Display for ParseSizeError {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        use self::ParseSizeErrorKind::*;

        match self.kind {
            InvalidFormat => write!(
                f,
                "invalid format for size '{}', which should be a non-empty \
                 sequence of digits followed by an optional 'K', 'M' or 'G' \
                 suffix",
                self.original
            ),
            InvalidInt(ref err) => write!(
                f,
                "invalid integer found in size '{}': {}",
                self.original, err
            ),
            Overflow => write!(f, "size too big in '{}'", self.original),
        }
    }
}

impl From<ParseSizeError> for std::io::Error {
    fn from(size_err: ParseSizeError) -> std::io::Error {
        std::io::Error::new(std::io::ErrorKind::Other, size_err)
    }
}

/// Parse a human readable size like `2M` into a corresponding number of bytes.
///
/// Supported size suffixes are `K` (for kilobyte), `M` (for megabyte) and `G`
/// (for gigabyte). If a size suffix is missing, then the size is interpreted
/// as bytes. If the size is too big to fit into a `u64`, then this returns an
/// error.
///
/// Additional suffixes may be added over time.

View on GitHub (pinned to 3fce3b5bb0)

Solutions

Lower the numeric portion so the scaled result fits in u64.
Drop the suffix and pass the exact byte count if you need a value near u64::MAX.
Validate that value <= u64::MAX / factor before calling, choosing an appropriate upper bound for your use case.

Example fix

// before
let n = parse_human_readable_size("9999999999999999G")?; // Overflow

// after
let n = parse_human_readable_size("9999999999G")?; // fits

Defensive patterns

Strategy: validation

Validate before calling

fn scaled_fits(s: &str) -> bool {
    let (d, suf) = s.split_at(s.bytes().take_while(|b| b.is_ascii_digit()).count());
    let Ok(v) = d.parse::<u64>() else { return false };
    let factor = match suf { "" => 1u64, "K" => 1<<10, "M" => 1<<20, "G" => 1<<30, _ => return false };
    v.checked_mul(factor).is_some()
}

Try / catch

let n = parse_human_readable_size(input)
    .unwrap_or_else(|e| { eprintln!("{e}"); u64::MAX });

Prevention

Pick realistic upper bounds for size flags rather than allowing near-u64::MAX values.
Use checked_mul in your own normalization layer before calling the parser.
Validate scaled results in CLI argument parsing and error early with guidance.

When it happens

Trigger: Passing a value like "9999999999999999G" or "18014398509481983K" where value * suffix-factor overflows u64 even though value alone is a valid u64.

Common situations: CLI/config size limits set unrealistically high with a K/M/G suffix; copy-pasted thresholds from documentation of a different tool with different overflow semantics.

Related errors

AI-assisted analysis of BurntSushi/ripgrep@3fce3b5bb0 (2026-08-06). Data as JSON: /data/errors/eb2517f307524114.json. Report an issue: GitHub.