asomers

asomers

Member Since 12 years ago

Longmont, Colorado, USA

Experience Points
87
follower
Lessons Completed
2
follow
Lessons Completed
8
stars
Best Reply Awards
118
repos

1693 contributions in the last year

Pinned
⚡ A powerful mock object library for Rust
⚡ Asynchronous file I/O for Tokio
⚡ Comparison of several Rust mocking libraries
⚡ Futures-aware lock primitives
⚡ Display ZFS datasets' I/O in real time
⚡ POSIX AIO bindings for mio
Activity
Jan
22
18 hours ago
open pull request

asomers wants to merge asomers/mockall

asomers
asomers

docs: update docs with synchronization example

just adds a link to the synchronization example in the main lib.rs doc

asomers
asomers

This link will be dead, because rustdoc doesn't include files in the examples/ directory. Instead, it's probably best to link to the file on Github.

pull request

asomers merge to asomers/mockall

asomers
asomers

docs: update docs with synchronization example

just adds a link to the synchronization example in the main lib.rs doc

pull request

asomers merge to asomers/mockall

asomers
asomers

docs: update docs with synchronization example

just adds a link to the synchronization example in the main lib.rs doc

Activity icon
issue

asomers issue rust-lang/cargo

asomers
asomers

cargo doc --examples ignores dev dependencies

Problem

With --examples, cargo doc is supposed to document your examples too. However, the examples may need dev dependencies in order to compile, and cargo doc does not include those, leading to errors about unresolved imports.

Steps

  1. git clone [email protected]:asomers/mockall.git
  2. cd mockall
  3. cargo doc --examples
...
error[E0432]: unresolved import `mockall_double`
 --> mockall/examples/ffi.rs:8:5
  |
8 | use mockall_double::double;
  |     ^^^^^^^^^^^^^^ use of undeclared crate or module `mockall_double`
  |
help: there is a crate or module with a similar name
  |
8 | use mockall_derive::double;
  |     ~~~~~~~~~~~~~~
...

Possible Solution(s)

cargo doc --examples should resolve dev-dependencies, just like cargo check --examples does.

Notes

No response

Version

> cargo version --verbose
cargo 1.60.0-nightly (95bb3c92b 2022-01-18)
release: 1.60.0-nightly
commit-hash: 95bb3c92bf516017e812e7f1c14c2dea3845b30e
commit-date: 2022-01-18
host: x86_64-unknown-freebsd
libgit2: 1.3.0 (sys:0.13.23 vendored)
libcurl: 7.80.0-DEV (sys:0.4.51+curl-7.80.0 vendored ssl:OpenSSL/1.1.1l)
os: FreeBSD 14.0-CURRENT [64-bit]
Activity icon
delete

asomers in asomers/libc delete branch fspacectl

deleted time in 12 hours ago
Jan
21
1 day ago
pull request

asomers merge to nix-rust/nix

asomers
asomers

sys/termios: add cross-platform API for arbitrary baud rates

This commit adds

pub struct ArbitraryBaudRate(pub u32);
impl TryFrom<ArbitraryBaudRate> for BaudRate { ... }

such that arbitrary baud rates can be specified on systems that otherwise do not support it (e.g. Linux) via abstraction.

The one problem I see with this implementation is the duplication of the BaudRate enum. Removing the duplication would require a new macro, which may be too complex for this feature to warrant implementation.

asomers
asomers

Why add the ArbitraryBaudRate structure? I think implementing TryFrom<u32> directly on BaudRate should be fine.

open pull request

asomers wants to merge nix-rust/nix

asomers
asomers

uclibc support

uclibc is a libc alternative (peer to glibc and musl) which is used in low-resource embedded linux applications.

It's supported in rust as the target_env of several tier 3 targets, but nix currently doesn't build. This patch provides a few customizations to get uclibc building.

To test:

Thanks for your consideration!

asomers
asomers

Wow, that's some surprisingly basic functionality to be broken in user-mode emulation.

open pull request

asomers wants to merge nix-rust/nix

asomers
asomers

uclibc support

uclibc is a libc alternative (peer to glibc and musl) which is used in low-resource embedded linux applications.

It's supported in rust as the target_env of several tier 3 targets, but nix currently doesn't build. This patch provides a few customizations to get uclibc building.

To test:

Thanks for your consideration!

asomers
asomers

Why disable this entire module?

pull request

asomers merge to nix-rust/nix

asomers
asomers

uclibc support

uclibc is a libc alternative (peer to glibc and musl) which is used in low-resource embedded linux applications.

It's supported in rust as the target_env of several tier 3 targets, but nix currently doesn't build. This patch provides a few customizations to get uclibc building.

To test:

Thanks for your consideration!

pull request

asomers merge to nix-rust/nix

asomers
asomers

uclibc support

uclibc is a libc alternative (peer to glibc and musl) which is used in low-resource embedded linux applications.

It's supported in rust as the target_env of several tier 3 targets, but nix currently doesn't build. This patch provides a few customizations to get uclibc building.

To test:

Thanks for your consideration!

open pull request

asomers wants to merge nix-rust/nix

asomers
asomers

Suppress clippy::not_unsafe_ptr_arg_deref in mqueue, ptrace

Fix the BSD builds on nightly.

asomers
asomers

Unfortunately, Clippy is right about this. Since mqd_t is a typedef, the user is allowed to do pretty much anything with it. As an example, this code will segfault:

#[test]
fn invalid_mqd_t() {
    let mqd: libc::mqd_t = std::ptr::null_mut();
    mq_close(mqd).unwrap();
}

I think Nix should fix this by defining a Newtype around mqd_t.

open pull request

asomers wants to merge nix-rust/nix

asomers
asomers

Suppress clippy::not_unsafe_ptr_arg_deref in mqueue, ptrace

Fix the BSD builds on nightly.

asomers
asomers

I think technically this doesn't violate Rust's safety rules. libc::ptrace doesn't dereference those addresses. Instead, it passes them to the kernel as-is. So from a safety perspective, this is similar to a Rust function that accepts a raw pointer argument but does nothing more than print its debugging form. OTOH, you could make the argument that since any foreign function call is unsafe, and we don't really know what ptrace does, that the entire ptrace API ought to be unsafe. I usually hew to the narrow technical definition of unsafe, but in this case I think making the entire API unsafe would be sensible. It would probably match users' expectations.

pull request

asomers merge to nix-rust/nix

asomers
asomers

Suppress clippy::not_unsafe_ptr_arg_deref in mqueue, ptrace

Fix the BSD builds on nightly.

pull request

asomers merge to nix-rust/nix

asomers
asomers

Suppress clippy::not_unsafe_ptr_arg_deref in mqueue, ptrace

Fix the BSD builds on nightly.

Activity icon
issue

asomers issue comment rust-lang/libc

asomers
asomers

Add fspacectl, new in FreeBSD 14

asomers
asomers

I rebased the changes, derived the extra traits, and made spacectl_range's fields public.

push

asomers push asomers/libc

asomers
asomers

linux/android aarch64 add user_regs_struct.

asomers
asomers

Fix/remove deprecated DragonFly items

These items were recently deprecated on DragonFly, either because the platform does not define them or because they were out of date.

asomers
asomers

Add mlock2 on Android and Linux.

asomers
asomers

dragonflybsd adding few new ioctl queries

asomers
asomers

Add riscv64-unknown-freebsd support

asomers
asomers

Add missing FreeBSD mount items

asomers
asomers

Auto merge of #2572 - GuillaumeGomez:mount-items, r=Amanieu

Add missing FreeBSD mount items

asomers
asomers

ptrace_coredump ptrace query addition for FreeBSD 14.

asomers
asomers

Auto merge of #2574 - devnexen:fbsd_14_pt_coredump, r=Amanieu

ptrace_coredump ptrace query addition for FreeBSD 14.

asomers
asomers
asomers
asomers

Update to the latest released wasi-libc and declare getcwd/chdir

Update to the latest version of wasi-libc which corresponds to the version in the wasi-sdk 14.0 release.

And, add declarations for getcwd and chdir, which are now provided by wasi-libc.

asomers
asomers

Add more linux ioctl constansts: BLKSSZGET and BLKPBSZGET

asomers
asomers

Define max_align_t for wasi.

WASI has a normal max_align_t.

asomers
asomers
Add `#[allow(missing_debug_implementations)]` to WASI's `max_align_t`.
asomers
asomers

Auto merge of #2577 - sunfishcode:sunfishcode/wasi-max-align-t, r=Amanieu

Define max_align_t for wasi.

WASI has a normal max_align_t.

asomers
asomers

Auto merge of #2565 - GuillaumeGomez:procstat, r=Amanieu

Add devstat items

asomers
asomers

Upgrade crate version to 0.2.109

asomers
asomers

Auto merge of #2568 - devnexen:dfbsd_ioctl_new_queries, r=Amanieu

dragonflybsd adding few new ioctl queries

asomers
asomers

Auto merge of #2575 - sunfishcode:sunfishcode/wasi-getcwd, r=Amanieu

Update to the latest released wasi-libc and declare getcwd/chdir

Update to the latest version of wasi-libc which corresponds to the version in the wasi-sdk 14.0 release.

And, add declarations for getcwd and chdir, which are now provided by wasi-libc.

commit sha: be392861b6c23321baf54ffd8f7c931ae6b9e157

push time in 1 day ago
Jan
20
2 days ago
started
started time in 2 days ago
push

asomers push asomers/libc

asomers
asomers

Delete FreeBSD's MNTK_ constants

These are only for the kernel's internal use and aren't exposed to userland. They also aren't stable across versions, and may be changed or deleted at any time. For example, by https://github.com/freebsd/freebsd-src/commit/4dcdf3987c1cc95d0d344468e8aa15452254691c

asomers
asomers

Update the FreeBSD 14 CI image

commit sha: 39b5891b725364e1f2c1567f79b3438a65185d15

push time in 2 days ago
pull request

asomers pull request rust-lang/libc

asomers
asomers

Delete unstable FreeBSD contants

  • KERN_STACKTOP was recently removed upstream, and has never been included in a stable FreeBSD release
  • The MNTK_ flags are for kernel use only and aren't visible to userland

cc @GuillaumeGomez

Activity icon
created branch

asomers in asomers/libc create branch no-kern-stacktop

createdAt 2 days ago
Activity icon
delete

asomers in bfffs/bfffs delete branch redundant-clone

deleted time in 2 days ago
push

asomers push bfffs/bfffs

asomers
asomers

Eliminate a redundant clone in Fs::deallocate

asomers
asomers

Merge pull request #138 from bfffs/redundant-clone

Eliminate a redundant clone in Fs::deallocate

commit sha: 59e6701939b3efab1d26b6a226df25314141947b

push time in 2 days ago
pull request

asomers pull request bfffs/bfffs

asomers
asomers

Eliminate a redundant clone in Fs::deallocate

Jan
18
4 days ago
Activity icon
issue

asomers issue comment nix-rust/nix

asomers
asomers

Change Sockaddr to a union

PR #1504 addresses a few safety and soundness issues with our Sockaddr type, which all boil down to "We should never create a &T reference if the entire T isn't initialized". But in reviewing it, I realized another problem: many Nix functions force the user to allocate a struct large enough for any type of sockaddr, even if they know exactly which type they need. For example, nix::sys::socket::bind takes an enum Sockaddr as its argument, which can be very large, even though all it does is immediately transform that argument into a pointer. Many Nix users undoubtedly know which type of Sockaddr they need before they call bind, but we force them to allocate a whole enum Sockaddr. And that begs the question: why use an enum at all? These types are basically already an enum in C. They can all be cast to and from sockaddr and sockaddr_storage, using the s*_family field as a discriminator. So here is my proposal for how to fix the problems raised by #1504 , stop requiring such large allocations, and make the sockaddr types more ergonomic too:

  • Create a SockaddrLike trait, mostly because for the as_ffi_pair method. The trait will be sealed, because it requires the sa_family_t and sa_len fields to be located at fixed offsets.
  • Create newtypes for every specific sockaddr type, all with #[repr(transparent)].
  • Create a Rust union for SockaddrStorage. Thanks to the sa_family_t tag, this union will be safely, falliably convertible to the other sockaddr types.
  • Change all functions like bind to accept a generic parameter of any SockaddrLike type.
  • Deprecate enum Sockaddr and related functions.

@coolreader18 what do you think of this idea? Here's an outline of the code:

/// Anything that, in C, can be cast back and forth to `sockaddr`.
pub trait SockaddrLike: private::Sealed {
    const FAMILY: AddressFamily;

    // Unsafe constructor from a variable length source
    // Some C APIs from provide `len`, and others do not.  If it's provided it
    // will be validated.  If not, it will be guessed based on the family.
    unsafe from_raw(addr: *const libc::sockaddr, len: Option<libc::socklen_t>)
        -> Result<Self> {...}

    // The next three methods have the same implementation for all concrete
    // types, since the trait is sealed!  This works because all implementors
    // are #[repr(transparent)] and the socklen and sa_family fields are located
    // at the same offset for all structs
    fn family(&self) -> AddressFamily {...}
    fn socklen(&self) -> socklen_t {...}
    // Used for many syscalls
    fn as_ffi_pair(&self) -> (*const libc::sockaddr, libc::socklen_t) {...}
}

mod private {
    pub trait Sealed {}
}

#[repr(transparent)]
pub struct Sockaddr(libc::sockaddr);
impl SockaddrLike for Sockaddr {...}

#[repr(transparent)]
pub struct SockaddrIn(libc::sockaddr_in);
impl SockaddrLike for SockaddrIn {...}

#[repr(C)]
pub union SockaddrStorage {
    sa: Sockaddr,
    sin: SockaddrIn,
    storage: libc::sockaddr_storage,
    // And several other types, too
}
impl SockaddrLike for SockaddrStorage {...}

impl SockaddrStorage {
    // Safe because it validates all fields
    pub fn as_sockaddr_in(&self) -> Result<&SockaddrIn> {...}
}

// Conversions by value from specific to generic are always safe, and will
// usually increase the size of the structure.
impl From<SockaddrIn> for SockaddrStorage {...}

// Conversions from generic to specific are falliable
impl TryFrom<SockaddrStorage> for SockaddrIn {...}

// These functions accept any SockaddrLike input, and do not necessarily require
// allocating any large Enum types.
pub fn bind<T: SockaddrLike>(fd: RawFd, addr: &T) -> Result<()> {...}
pub fn getpeername<T: SockaddrLike>(fd: RawFd) -> Result<T> {...}
asomers
asomers

No, that was just one step. I've got a WIP branch for the rest of the changes.

pull request

asomers pull request bfffs/bfffs

asomers
asomers

Eliminate a redundant clone in Fs::deallocate

Activity icon
created branch

asomers in bfffs/bfffs create branch redundant-clone

createdAt 4 days ago
Jan
17
5 days ago
Activity icon
delete

asomers in bfffs/bfffs delete branch integration_tests

deleted time in 5 days ago
push

asomers push bfffs/bfffs

asomers
asomers

Add integration tests for the bfffs crate

asomers
asomers
asomers
asomers

Merge pull request #137 from bfffs/integration_tests

Integration tests

commit sha: e7c2433f722a8f31101ded20ded3020224b65e52

push time in 5 days ago
pull request

asomers pull request bfffs/bfffs

asomers
asomers

Integration tests

Previous