BurntSushi/ripgrep · error

host name max limit ({}) overflowed usize

Error message

host name max limit ({}) overflowed usize

What it means

On Unix, hostname() calls libc::sysconf(_SC_HOST_NAME_MAX) to size the hostname buffer. If sysconf returns a non-negative value that nonetheless cannot be converted into usize (usize::try_from fails), this error is produced. It is a defensive guard against a pathological sysconf result on a broken or emulated libc.

Source

Thrown at crates/cli/src/hostname.rs:52

#[cfg(unix)]
fn gethostname() -> io::Result<OsString> {
    use std::os::unix::ffi::OsStringExt;

    // SAFETY: There don't appear to be any safety requirements for calling
    // sysconf.
    let limit = unsafe { libc::sysconf(libc::_SC_HOST_NAME_MAX) };
    if limit == -1 {
        // It is in theory possible for sysconf to return -1 for a limit but
        // *not* set errno, in which case, io::Error::last_os_error is
        // indeterminate. But untangling that is super annoying because std
        // doesn't expose any unix-specific APIs for inspecting the errno. (We
        // could do it ourselves, but it just doesn't seem worth doing?)
        return Err(io::Error::last_os_error());
    }
    let Ok(maxlen) = usize::try_from(limit) else {
        let msg = format!("host name max limit ({}) overflowed usize", limit);
        return Err(io::Error::new(io::ErrorKind::Other, msg));
    };
    // maxlen here includes the NUL terminator.
    let mut buf = vec![0; maxlen];
    // SAFETY: The pointer we give is valid as it is derived directly from a
    // Vec. Similarly, `maxlen` is the length of our Vec, and is thus valid
    // to write to.
    let rc = unsafe {
        libc::gethostname(buf.as_mut_ptr().cast::<libc::c_char>(), maxlen)
    };
    if rc == -1 {
        return Err(io::Error::last_os_error());
    }
    // POSIX says that if the hostname is bigger than `maxlen`, then it may
    // write a truncate name back that is not necessarily NUL terminated (wtf,
    // lol). So if we can't find a NUL terminator, then just give up.
    let Some(zeropos) = buf.iter().position(|&b| b == 0) else {
        let msg = "could not find NUL terminator in hostname";
        return Err(io::Error::new(io::ErrorKind::Other, msg));

View on GitHub (pinned to 3fce3b5bb0)

Solutions

  1. Treat this as a system/libc defect: report or patch the environment returning a bogus _SC_HOST_NAME_MAX.
  2. Avoid the hostname() call and read the hostname from an OS file (e.g. /etc/hostname) or an env var as a workaround.
  3. Upgrade/restart the affected host so sysconf returns a sane value.

Example fix

// before
let name = grep_cli::hostname()?;

// after (fallback for broken sysconf)
let name = match grep_cli::hostname() {
    Ok(n) => n,
    Err(_) => std::fs::read_to_string("/etc/hostname")
        .unwrap_or_default().trim_end().into(),
};
Defensive patterns

Strategy: fallback

Try / catch

let host = match grep_cli::hostname() {
    Ok(n) => n,
    Err(_) => std::fs::read_to_string("/etc/hostname")
        .unwrap_or_default().trim_end().into(),
};

Prevention

When it happens

Trigger: sysconf(_SC_HOST_NAME_MAX) returns a positive c_long that exceeds usize::MAX (only possible on targets where c_long is wider than, or a different signedness than, the pointer-sized usize) and usize::try_from(limit) returns Err.

Common situations: Running under a buggy syscall emulation layer, a container/VM with a misconfigured sysconf, or an unusual ABI where long is 8 bytes but usize is 4 bytes (rare 32-bit Unix variants). Practically never seen on mainstream Linux/macOS.

Related errors


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