DeVault: Announcing the Hare programming language [LWN.net]

DeVault: Announcing the Hare programming language

Posted May 3, 2022 17:16 UTC (Tue) by tialaramex (subscriber, #21167)
In reply to: DeVault: Announcing the Hare programming language by felix.s
Parent article: DeVault: Announcing the Hare programming language

> Last I checked, the direction Rust seems to be going is to swallow the bitter pill and define usize to be uintptr_t, accepting the resulting memory bloat in situations where size_t happens to be smaller.

I would say that Aria's "experiment" in nightly suggests exactly the opposite. Rust may choose to promise only that usize is the same size as the address, not the pointer - deliver APIs that reflect this more sophisticated understanding of how provenance works, and tell everybody whose black magic now doesn't work on CHERI that's too bad, try again with new knowledge.

https://doc.rust-lang.org/nightly/core/primitive.pointer....

to post comments

DeVault: Announcing the Hare programming language

Posted May 3, 2022 18:25 UTC (Tue) by felix.s (guest, #104710) [Link] (1 responses)

Let’s hope that it will be fruitful. Still, the conflation of those two is not the only such ‘all the world’s x86 and ARM’ assumption that I am saddened to see in Rust. I think it’s the ‘weird’ (segmented, non-twos’-complement, narrow address space, maybe even non-octet-based, etc.) architectures that are the ones that could benefit the most from a Rust port, because they are the ones starved the most for any good tooling. I would love to see some day a Rust port to Win16 or DOS, which is to say, to x86-16 with a ‘large’ or ‘huge’ memory model. And some may disagree with me, but I think a commitment to backwards compatibility is one of the few things that C ought to be applauded for.

DeVault: Announcing the Hare programming language

Posted May 3, 2022 18:42 UTC (Tue) by joib (subscriber, #8541) [Link]

There is some ongoing work to make Rust view of pointers more generic. That is, to break the assumptions that usize (roughly equivalent to size_t for you C-heads) is the same size as a pointer, and that a pointer->usize->pointer roundtrip doesn't lose information. AFAICS the motivation is not to work with all those weird old and obsolete architectures, but more to work with things like CHERI (including ARM Morello which is an implementation of CHERI), but I guess some of that work might help with stuff like segmented architectures as well.