cp: integer conversion panic on ppc64le

[kaathewisegit]

I'm packaging Nushell 0.105 for Alpine right now, and ppc64le is one of the supported architectures. Nushell's cp, which uses uu_cp underneath, failed the tests because of a panic:

---- commands::ucp::copies_files_with_glob_metachars::case_1 stdout ----
=== stderr
Error:   × Main thread panicked.
  ├─▶ at /home/buildozer/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/
  │   uu_cp-0.1.0/src/platform/linux.rs:69:54
  ╰─▶ called `Result::unwrap()` on an `Err` value: TryFromIntError(())
  help: set the `RUST_BACKTRACE=1` environment variable to display a
        backtrace.
thread 'commands::ucp::copies_files_with_glob_metachars::case_1' panicked at crates/nu-command/tests/commands/ucp.rs:1014:9:
assertion failed: actual.err.is_empty()

Full log: https://gitlab.alpinelinux.org/kaathewise/aports/-/jobs/1891916

This is the code which fails:

coreutils/src/uu/cp/src/platform/linux.rs

Lines 64 to 72 in 18b963e

	// Using .try_into().unwrap() is required as glibc, musl & android all have different type for ioctl()
	#[allow(clippy::unnecessary_fallible_conversions)]
	let result = unsafe {
	libc::ioctl(
	dst_fd,
	linux_raw_sys::ioctl::FICLONE.try_into().unwrap(),
	src_fd,
	)
	};

[VenetiaFurtado]

@kaathewisegit , Is there a way to reproduce it on a x86 machine?

[kaathewisegit]

I don't think so, @VenetiaFurtado, all of the tests pass on x86. QEMU could work, though

[dezgeg]

On ppc64, FICLONE is pub const FICLONE: u32 = 2147783689; which can't be directly converted into i32 (which is what musl ioctl takes). Wrapping conversion is needed from the linux_raw_sys constant there (but done in a way that also compiles on other platorms)

[maxfilov]

I'm quite new to Rust and I'm looking around for now. I've opened a PR #8637 with a fix that looks too simple to be the real fix. I expected that there would be some obstacles on the way. @dezgeg Can you or someone else criticize it if possible?

[dezgeg]

I'm quite new to Rust and I'm looking around for now. I've opened a PR #8637 with a fix that looks too simple to be the real fix. I expected that there would be some obstacles on the way. @dezgeg Can you or someone else criticize it if possible?

Good find, that does sound like it should work (assuming the linter likes it).

[maxfilov]

@dezgeg in fact there is libc::FICLONE, I can simply use it instead of linux_raw_sys
smth like

let result = unsafe { libc::ioctl(dst_fd, libc::FICLONE, src_fd) };

[maxfilov]

opened a Pull Request
#8641