ICE: std::os::getcwd fails too eagerly

[mahkoh]

This means that getcwd is unusable outside of toy programs. There is no way to see if this function might fail before calling it or to get the path in a safe way.

rustc uses getcwd and will ICE under the conditions described in this issue.

[thehydroimpulse]

It would probably be better to return a result instead of failing.

[mahkoh]

Naturally an IoResult would be best. For now I've fixed this locally:

static BUF_BYTES: uint = 4096;

#[cfg(unix)]
pub fn getcwd() -> Option<Path> {
    use std::c_str::CString;
    use libc::{c_char, size_t};

    let mut buf = [0 as c_char, ..BUF_BYTES];
    unsafe {
        if libc::getcwd(buf.as_mut_ptr(), buf.len() as size_t).is_null() {
            None
        } else {
            Some(Path::new(CString::new(buf.as_ptr(), false)))
        }
    }
}

#[cfg(windows)]
pub fn getcwd() -> Option<Path> {
    use libc::DWORD;
    use libc::GetCurrentDirectoryW;

    let mut buf = [0 as u16, ..BUF_BYTES];
    unsafe {
        if libc::GetCurrentDirectoryW(buf.len() as DWORD, buf.as_mut_ptr()) == 0 {
            return None;
        }
    }
    match String::from_utf16(std::str::truncate_utf16_at_nul(buf)) {
        Some(s) => Some(Path::new(s)),
        _ => None,
    }
}

And while we're at it: BUF_BYTES is 2048 in the stdlib which is way too small.

[mahkoh]

Apparently there is no path length limit on linux. glibc has the following extension that could be used to handle this:

       As  an  extension  to the POSIX.1-2001 standard, glibc's getcwd() allocates
       the buffer dynamically using malloc(3) if buf is NULL.  In this  case,  the
       allocated buffer has the length size unless size is zero, when buf is allo‐
       cated as big as necessary.  The caller should free(3) the returned buffer.

Not sure about jemalloc <-> malloc here. FreeBSD has the same extension.

[mahkoh]

@huonw Not sure why you changed the title. You cannot use getcwd in its current form in a safe way if you don't want your program to crash. Even if the user just deleted the directory your program was started from, your program will crash. If your program was started with a very long cwd path? Crash. getcwd is literally useless in its current form. No need to sugarcoat the issue.

Furthermore your title is misleading since this is not the only issue. getcwd also fails if the buffer is too small. That means that the documentation is incorrect.

[huonw]

The original title was unnecessarily inflammatory and nonspecific; I changed it to accurately reflect the problem: it fail!s instead of handling errors properly.

Furthermore your title is misleading since this is not the only issue. getcwd also fails if the buffer is too small.

That is included in "failing too eagerly": it doesn't handle this 'error' properly.

That means that the documentation is incorrect.

Your title didn't address this either.

[brson]

cc @aturon