silence warning about cast

[Freax13]

The lint exists to warn about incompatibilities with different architectures, but this code only runs on x86-64 anyway, so portability is not a concern.

This fixes a nightly breakage.

[phil-opp]

Thanks a lot! As mentioned inline, I think it would be good to add a target_pointer_width check. Otherwise this seems ready to be merged!

[phil-opp]

I guess we should also decide how to deal with compilations for ARM-based systems. Throwing lots of errors in inline asm is not that nice. I guess we have the following options:

• Add a top-level compile_error when building for non-x86 systems.
• Less drastic: Invoke a compile_error when the instructions or abi_x86_interrupt features are enabled on non-x86 systems.
• Use conditional compilation to disable all functions that use inline asm or core::arch::x86_64 on non-x86 architectures.
  • Either on a per-function base, or by making the instructions feature a no-op on non-x86_64 systems.

I'm in favor of option 2 or 3 because I think that parts of this crate could still be useful on ARM-based systems. For example, you could use the VirtAdd::try_new function in a build system to verify that a configured address is valid on the target system.

(It's probably best to do this in a follow-up PR as it's not directly related to this change. I just wanted to start the discussion.)

[Freax13]

I guess we should also decide how to deal with compilations for ARM-based systems. Throwing lots of errors in inline asm is not that nice. I guess we have the following options:

• Add a top-level compile_error when building for non-x86 systems.

• Less drastic: Invoke a compile_error when the instructions or abi_x86_interrupt features are enabled on non-x86 systems.

• Use conditional compilation to disable all functions that use inline asm or core::arch::x86_64 on non-x86 architectures.

  • Either on a per-function base, or by making the instructions feature a no-op on non-x86_64 systems.

I'm in favor of option 2 or 3 because I think that parts of this crate could still be useful on ARM-based systems. For example, you could use the VirtAdd::try_new function in a build system to verify that a configured address is valid on the target system.

Option 1 would be a breaking change. Option 2 and 3 are not mutually exclusive: If we only add a compiler_error!, but don't disable the asm! code, the user will still be confronted with all the error messages our uses of asm! will cause. That said, it's likely the error generated by compiler_error! is one of the (if not the) first error messages shown to the user.

(It's probably best to do this in a follow-up PR as it's not directly related to this change. I just wanted to start the discussion.)

Agreed.

[Freax13]

I guess we should also decide how to deal with compilations for ARM-based systems. Throwing lots of errors in inline asm is not that nice. I guess we have the following options:

• Add a top-level compile_error when building for non-x86 systems.

• Less drastic: Invoke a compile_error when the instructions or abi_x86_interrupt features are enabled on non-x86 systems.

• Use conditional compilation to disable all functions that use inline asm or core::arch::x86_64 on non-x86 architectures.

  • Either on a per-function base, or by making the instructions feature a no-op on non-x86_64 systems.

I'm in favor of option 2 or 3 because I think that parts of this crate could still be useful on ARM-based systems. For example, you could use the VirtAdd::try_new function in a build system to verify that a configured address is valid on the target system.

Option 1 would be a breaking change.

Our CI even tests that ARM builds work:

x86_64/.github/workflows/build.yml

Lines 70 to 73 in 615248f

	- name: "Build on non x86_64 platforms"
	run: |
	cargo build --target i686-unknown-linux-gnu --no-default-features --features nightly
	cargo build --target thumbv7em-none-eabihf --no-default-features --features nightly

[phil-opp]

If we only add a compiler_error!, but don't disable the asm! code, the user will still be confronted with all the error messages our uses of asm! will cause.

Good point!

[phil-opp]

I just removed the Test (macos-latest) CI job from the list of required checks to make this PR mergable. We should make the macos-12 required after merging.

[phil-opp]

I opened a follow-up PR to implement the needed cfg changes: #483