| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Now that Nix's weird error types are eliminated, there's no reason not
to simply use Errno as the Error type.
|
|
For many of Nix's consumers it be convenient to easily convert a Nix
error into a std::io::Error. That's currently not possible because of
the InvalidPath, InvalidUtf8, and UnsupportedOperation types that have
no equivalent in std::io::Error.
However, very few of Nix's public APIs actually return those unusual
errors. So a more useful API would be for Nix's standard error type to
implement Into<std::io::Error>.
This commit makes Error a simple NewType around Errno. For most
functions it's a drop-in replacement. There are only three exceptions:
* clearenv now returns a bespoke error type. It was the only Nix
function whose error couldn't be cleanly mapped onto an Errno.
* sys::signal::signal now returns Error(Errno::ENOTSUP) instead of
Error::UnsupportedOperation when the user passes an incompatible
argument to `handler`.
* When a NixPath exceeds PATH_MAX, it will now return
Error(Errno::ENAMETOOLONG) instead of Error::InvalidPath.
In the latter two cases there is now some abiguity about whether the
error code was generated by Nix or by the OS. But I think the ambiguity
is worth it for the sake of being able to implement Into<io::Error>.
This commit also introduces Error::Sys() as a migration aid. Previously
that as an enum variant. Now it's a function, but it will work in many
of the same contexts as the original.
Fixes #1155
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Previously they had to be consts in the errno module, because associated
consts weren't supported until Rust 1.20.0. Now that they're associated
consts, they can be used interchangeably with regular Errno enum
variants.
|
|
Previously these were aliases for UnknownErrno. Now, they're compile
errors.
|
|
Hopefully fix unreliability in unistd::alarm's doc test
|
|
|
|
|
|
|
|
Add a note in the documentation for sched::clone to point out that the
stack pointer does not neet to be a reference to the highest address of
the stack.
Users who simply read the manpages for clone(2) might assume that they
will need to use unsafe pointer arithmetics in order to create a
reference to the highest address of their buffer, rather than providing
their buffer directly.
|
|
|
|
|
|
* Fix race conditions in the tests. Two tests were grabbing a mutex but
immediately dropping it. Thank you, Clippy.
* Remove vestigial Windows support. Remove some code added to support
Windows in 2015. Nix is no longer intended to ever run on Windows.
* Various other minor Clippy lints.
|
|
1437: Add MS_LAZYTIME flag r=asomers a=ManaSugi
MS_LAZYTIME (since Linux 4.0) reduces on-disk updates of inode
timestamps (atime, mtime, ctime) by maintaining these changes only in memory.
MS_LAZYTIME is available from `libc` v0.2.95.
Signed-off-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>
Co-authored-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>
|
|
MS_LAZYTIME (since Linux 4.0) reduces on-disk updates of inode
timestamps (atime, mtime, ctime) by maintaining these changes only in memory.
Signed-off-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>
|
|
* libc::aiocb must not be moved while the kernel has a pointer to it.
This change enforces that requirement by using std::pin.
* Split LioCbBuilder out of LioCb. struct LioCb relied on the
(incorrect) assumption that a Vec's elements have a stable location in
memory. That's not true; they can be moved during Vec::push. The
solution is to use a Vec in the new Builder struct, but finalize it to
a boxed slice (which doesn't support push) before allowing it to be
submitted to the kernel.
* Eliminate owned buffer types. mio-aio no longer uses owned buffers
with nix::aio. There's little need for it in the world of
async/await. I'm not aware of any other consumers. This
substantially simplifies the code.
|
|
Suppress a build warning on Fuchsia
|
|
Beginning with 1.41.0, Rust considers it UB to zero-initialize a
function pointer, even if you try to hide it behind `mem::MaybeUninit`.
Suppress this warning to fix the build until we come up with a better
permanent solution.
Issue #1441
|
|
It's not available from libc on that platform.
|
|
`sendfile64` is a Linux-specific call with a wider type for the `offset`
argument than `sendfile`.
This is largely a copy of the existing `sendfile` function and
associated test.
|
|
|
|
|
|
Hopefully improve unistd::alarm::set's doc test's reliability
|
|
|
|
1429: constify from_raw and as_raw for Uid, Gid and Pid and Uid::is_root r=asomers a=Blub
Make some integer wrapper methods `const fn`.
* `Uid::from_raw`
* `Uid::as_raw`
* `Uid::is_root`
* `Gid::from_raw`
* `Gid::as_raw`
* `Pid::from_raw`
* `Pid::as_raw`
(Changelog mentions rust 1.40.0 as minimum required version which seems to compile this fine (using 1.40.0 from rustup))
Co-authored-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
|
|
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
|
|
|
|
1402: Support TIMESTAMPNS r=asomers a=WiSaGaN
This adds support of linux TIMESTAMPNS.
The code is mostly copied paste from https://github.com/nix-rust/nix/pull/663
Co-authored-by: Lu, Wangshan <wisagan@gmail.com>
|
|
1414: Fix corrupted sendmmsg() call r=asomers a=eaufavor
Before this fix, the buffer that holds cmsgs may move due to the resize()
call. That causes msg_hdr pointing to invalid memory, which ends up
breaking the sendmmsg() call, resulting in EINVAL.
This change fixes it by avoiding re-allocating the buffers.
Co-authored-by: Yuchen Wu <yuchen@cloudflare.com>
|
|
|
|
Before this fix, the buffer that holds cmsgs may move due to the resize()
call. That causes msg_hdr pointing to invalid memory, which ends up
breaking the sendmmsg() call, resulting in EINVAL.
This change fixes it by avoiding re-allocating the buffers.
|
|
1416: Use memoffset::offset_of instead of homegrown macro r=asomers a=asomers
The homegrown macro was fine in 2016, but at some point it technically
became UB. The memoffset crate does the same thing, but avoids UB when
using rustc 1.51.0 or later.
Fixes #1415
Co-authored-by: Alan Somers <asomers@gmail.com>
|
|
The homegrown macro was fine in 2016, but at some point it technically
became UB. The memoffset crate does the same thing, but avoids UB when
using rustc 1.51.0 or later.
Fixes #1415
|
|
We have one UNIX group that contains most of our users whose size is
about 20 kB, so `Group::from_name` is failing with ERANGE.
The discussion on PR #864 suggests that 1 MB is a reasonable maximum -
it follows what FreeBSD's libc does. (glibc appears to have no maximum
on the _r function and will just double the buffer until malloc fails,
but that's not particularly Rusty.)
|
|
1401: cleanup: remove redundant unwrap in Dir::from_fd r=asomers a=scottlamb
Co-authored-by: Scott Lamb <slamb@slamb.org>
|
|
|
|
|
|
Co-authored-by: Dominik Hassler <hadfl@omnios.org>
Co-authored-by: Joshua M. Clulow <josh@sysmgr.org>
|
|
Apparently the Linux kernel can return smaller sizes when the value in
the last element of sockaddr_ll (`sll_addr`) is smaller than the
declared size of that field.
|
|
libc removed it in version 0.2.87.
https://github.com/rust-lang/libc/pull/2079
|
|
After the child returns from a fork() of a multi-threaded process, it is
undefined behaviour to call non-async-signal-safe functions according to
POSIX. Since forkpty() is implemented in terms of fork(), those
restrictions should apply to it too.
|
|
|
|
|
|
|
