Skip to content

decmpfs 0.1.2 fails to compile on musl targets: FICLONE ioctl request typed c_ulong #1

Description

@jdx

clone_file in src/linux.rs (added in 0.1.2) declares the FICLONE request as libc::c_ulong:

// FICLONE = _IOW(0x94, 9, int) — stable since Linux 4.5.
const FICLONE: libc::c_ulong = 0x4004_9409;
let cloned = unsafe { libc::ioctl(dest_file.as_raw_fd(), FICLONE, src_file.as_raw_fd()) } == 0;

libc::ioctl's request parameter is libc::Ioctl, which is c_ulong on glibc but c_int on musl, so the crate fails to compile for every *-unknown-linux-musl target:

error[E0308]: mismatched types
    --> decmpfs-0.1.2/src/linux.rs:296:60
     |
 296 |   let cloned = unsafe { libc::ioctl(dest_file.as_raw_fd(), FICLONE, src_file.as_raw_fd()) } == 0;
     |                         -----------                        ^^^^^^^ expected `i32`, found `u64`
     |                         |
     |                         arguments to this function are incorrect
     |
note: function defined here
    --> libc-0.2.186/src/unix/linux_like/mod.rs:1731:20
     |
1731 |             pub fn ioctl(fd: c_int, request: Ioctl, ...) -> c_int;
error: could not compile `decmpfs` (lib) due to 1 previous error

Reproduce: cargo build --target x86_64-unknown-linux-musl (or aarch64-unknown-linux-musl) on 0.1.2. glibc, macOS, and Windows targets are unaffected.

Fix: cast at the call site, the way the other ioctls in the same file already do — libc::ioctl(dest_file.as_raw_fd(), FICLONE as _, src_file.as_raw_fd()) — or type the constant as libc::Ioctl. The comment above FS_IOC_GETFLAGS in that file already documents this exact hazard:

// `as _` at the call site casts it to whatever `libc::ioctl` expects per target
// (c_ulong on glibc, c_int on musl) — same 32 bits either way.

clone_file is the only ioctl call site in the file that omits the cast, so 0.1.0 built fine on musl and 0.1.2 does not. Still present on main at crates/decmpfs/src/linux.rs:295.

Context: this reached us as musl CI failures in jdx/aube after a lockfile bump to 0.1.2; we've pinned back to 0.1.0 for now. Happy to send a PR if that's useful.

This issue was generated by Claude.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions