std: use more LFS functions on Linux#31668
Conversation
bluss
added
the
relnotes
This follows the pattern already used for stat functions from rust-lang#31551. Now `ftruncate`, `lseek`, and `readdir_r` use their explicit 64-bit variants for LFS support, using wider `off_t` and `dirent` types. This also updates to `open64`, which uses no different types but implies the `O_LARGEFILE` flag. Non-Linux platforms just map their normal functions to the 64-bit names. r? @alexcrichton
|
What happens if someone writes the following on a 32bit platform? let file = File::from_raw_fd(libc::open(...)); // non LFS open
file.set_len(u32::MAX + 1);I assume (hope) this fails gracefully (or succeeds) but doesn't do anything weird. |
|
@Stebalien good question -- assuming you do cast that We'll also assume your file wasn't already >=2GB, or that AFAICT Rust doesn't care at all, so it's up to the kernel's behavior. System call Actually, the old behavior would have been the "weird" one, silently taking |
This follows the pattern already used for stat functions from #31551. Now `ftruncate`, `lseek`, and `readdir_r` use their explicit 64-bit variants for LFS support, using wider `off_t` and `dirent` types. This also updates to `open64`, which uses no different types but implies the `O_LARGEFILE` flag. Non-Linux platforms just map their normal functions to the 64-bit names. r? @alexcrichton
|
@cuviper Thanks. I just wanted to make sure that mixing and matching LFS/non LFS syscalls wouldn't' cause any problems (for backwards comparability). |
5 participants
This follows the pattern already used for stat functions from #31551. Now
ftruncate,lseek, andreaddir_ruse their explicit 64-bit variants forLFS support, using wider
off_tanddirenttypes. This also updates toopen64, which uses no different types but implies theO_LARGEFILEflag.Non-Linux platforms just map their normal functions to the 64-bit names.
r? @alexcrichton