Consider rust's strict_provenance?

[rujialiu]

Someone told me today that we should not assume C's size_t and rust's usize should be able to hold pointers because this is not the case on some emerging architectures (https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-947.pdf). Rust has a tracking issue on strict_provenance (rust-lang/rust#95228) that seems to be related to this kind of complexity, but it looks too complex to me, and it might be too early to consider this, but I think it's a good thing to make the code more clear/reliable and ready to new architectures. So I'm opening this issue in case anyone is interested in.

[rujialiu]

Looking at the projects that mentioned that rust issue, I found https://github.com/google/zerocopy quite interesting. The codes that I debugged a lot during porting to 32-bit, is somewhat similar to what zerocopy tries to do. While we don't neccesary need to use it directly, we can follow its development

[bakaq]

Strict provenance was just stabilized in Rust 1.84.0. I'm not sure we want to update the MSRV of the project immediately to benefit from it, but even if we don't it will make it much easier to port to strict provenance (even to the polyfill which doesn't need a MSRV bump) because of the lints.

Currently our MSRV is 1.77. Updating the MSRV too early may make it harder for distros such as Debian which lag behind to package the project. I couldn't find any specific MSRV policy for Debian, but their packaged Rust version is 1.63.0, which we are already well ahead anyway.

In my opinion it's very worth it to update the MSRV and port to strict provenance as soon as possible. It will probably fix a lot of UB we didn't even notice and make Miri much more effective.

[rujialiu]

Ah memories... The project I worked on (when I posted this) no longer use prolog (not the fault of scryer-prolog of course). But I'm still a fan of scryer-prolog and is keeping an eye on it.

[Skgland]

Strict provenance was just stabilized in Rust 1.84.0. I'm not sure we want to update the MSRV of the project immediately to benefit from it, but even if we don't it will make it much easier to port to strict provenance (even to the polyfill which doesn't need a MSRV bump) because of the lints.

Currently our MSRV is 1.77. Updating the MSRV too early may make it harder for distros such as Debian which lag behind to package the project. I couldn't find any specific MSRV policy for Debian, but their packaged Rust version is 1.63.0, which we are already well ahead anyway.

The upcoming debian release trixie is at 1.83¹ so just one version too old for stable strict_provenance, but I don't think that version is frozen yet so strict_provenance might still make it into the next debian release whenever that releases.

Footnotes

1. https://packages.debian.org/trixie/rust-all ↩

[Skgland]

The Transition and Toolchain Freeze for Debian Trixie has been announced for 2025-03-15 at https://release.debian.org/#release-dates, until then there is still time for the rust version to be updated. Looking at https://tracker.debian.org/pkg/rustc it looks 1.84 is just missing a few more positive tests results, i.e. waiting on CI. With 1.85 scheduled to be release 2025-02-20 stabilizing edition 2024 that might even be enough time for that to make it in.

[Skgland]

1.84 migrated to Debian Testing https://tracker.debian.org/news/1610833/rustc-1840dfsg1-2-migrated-to-testing/

[bakaq]

Update on this: Debian Trixie is already on 1.84, and it seems even 1.85 (which includes Rust Edition 2024) will make the cut before the freeze in April.

[Skgland]

1.85 made it in to trixie

Addendum: Also as rust is considered a toolchain package the relevant freeze window is already in March not in April.

[triska]

It will probably fix a lot of UB we didn't even notice and make Miri much more effective.

This seems to be an awesome and very worthwhile advantage!

It will likely save development time and yield a more correct system.