Rust assumes PATH_MAX is not a lie in a few places

[sstewartgallus]

See http://insanecoding.blogspot.ca/2007/11/pathmax-simply-isnt.html for some background. Basically, PATH_MAX just doesn't work.

Currently. Rust uses PATH_MAX in a few important places.

./src/libstd/sys/unix/fs.rs:377:let mut buf = vec![0;libc::PATH_MAX as usize];
./src/libstd/sys/unix/fs.rs:469:len = 1024; // FIXME: read PATH_MAX from C ffi?
./src/rt/rust_builtin.c:337:char buf[2*PATH_MAX], exe[2*PATH_MAX];
./src/rt/rust_builtin.c:380:snprintf(buf, 2*PATH_MAX, "%s/%s", paths[i], argv0);

Generally, the best approach to work around this is to loop and double a buffer in size until it is big enough in size to fill with the path or to query the size of the path of the file using fpathconf. I'm not sure if any filesystems on any modern OSes return -1 for the result of fpathconf. Letting things get too big opens up a DOS attack though so be careful I guess?

The fpathconf strategy or the doubling buffer strategy can be done with ./src/libstd/sys/unix/fs.rs:469 but I'm not sure how to handle the Rust cases that use realpath (unless realpath is reimplemented by hand). The C code can just use the NULL argument but I forget if there's a way to martial allocated by C data to Rust.