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
- Treat this as a system/libc defect: report or patch the environment returning a bogus _SC_HOST_NAME_MAX.
- Avoid the hostname() call and read the hostname from an OS file (e.g. /etc/hostname) or an env var as a workaround.
- 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
- Treat hostname() as fallible even on Unix and always provide a fallback.
- In tests/CI, prefer setting hostname via env to avoid depending on sysconf quirks.
- Report recurring sysconf failures to the platform/libc maintainer.
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.