BurntSushi/ripgrep · error

hostname could not be found on unsupported platform

Error message

hostname could not be found on unsupported platform

What it means

Returned by hostname() when compiled for a target that is neither Windows nor Unix (the function body is gated behind #[cfg(not(any(windows, unix)))]). On such targets there is no libc gethostname and no Win32 computer-name API to call, so the routine cannot produce a hostname and fails immediately. It exists so the crate compiles on exotic tier-3 targets like wasm32 while still erroring cleanly at runtime.

Source

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

///
/// On Windows, this currently uses the "physical DNS hostname" computer name.
/// This may change in the future.
///
/// On Unix, this returns the result of the `gethostname` function from the
/// `libc` linked into the program.
pub fn hostname() -> io::Result<OsString> {
    #[cfg(windows)]
    {
        use winapi_util::sysinfo::{ComputerNameKind, get_computer_name};
        get_computer_name(ComputerNameKind::PhysicalDnsHostname)
    }
    #[cfg(unix)]
    {
        gethostname()
    }
    #[cfg(not(any(windows, unix)))]
    {
        Err(io::Error::new(
            io::ErrorKind::Other,
            "hostname could not be found on unsupported platform",
        ))
    }
}

#[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

View on GitHub (pinned to 3fce3b5bb0)

Solutions

  1. If you do not actually need wasm/redox support, build for a supported target (x86_64-linux, aarch64-apple-darwin, or any windows/msvc target) so the windows or unix branch compiles instead.
  2. If you must run on the unsupported platform, supply the hostname yourself from an environment variable or config and avoid calling hostname().
  3. Feature-gate or stub the call site that invokes hostname() when targeting the unsupported platform, returning a sensible default.

Example fix

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

// after (guarded for wasm/unsupported targets)
#[cfg(any(windows, unix))]
let host = grep_cli::hostname()?;
#[cfg(not(any(windows, unix)))]
let host = std::env::var("HOSTNAME").unwrap_or_default();
Defensive patterns

Strategy: validation

Validate before calling

// Only call hostname() on supported targets.
const SUPPORTED: bool = cfg!(any(windows, unix));
fn can_get_hostname() -> bool { SUPPORTED }

Try / catch

let host = grep_cli::hostname();
if let Err(e) = host {
    // fall back to env or a default; expected on wasm/non-unix-non-windows
    log::warn!("hostname unavailable: {e}");
}

Prevention

When it happens

Trigger: Calling grep_cli::hostname() (directly or transitively through a tool that embeds it) on a target triple such as wasm32-wasi, wasm32-unknown-unknown, or any redox/wasix build where neither the windows nor unix cfg branch is selected.

Common situations: Cross-compiling a ripgrep-based binary or library to WebAssembly; running grep tooling inside a wasm sandbox/edge runtime; building for an embedded niche target that lacks a host-name concept.

Related errors


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