Feedback request: Raw pointer validity at address 0x0

[H4n-uL]

Hi all,

I'm working on an RFC about making address 0x0 valid for raw pointer operations and putting a "zeroable reference" alongside the non-zero one, motivated by bare-metal targets where hardware places valid object at that RAM address.

Latest RFC here: https://universet-uendelege.notion.site/Dereferenceable-Zero-322fb761f47480a5a825f12bc081bbf8

A couple of things I'd particularly appreciate perspectives on:

• Does the problem described match real barriers you've encountered or foreseen?
• In your experience, would reliance on inline assembly or volatile workarounds to access address 0x0 pose issues during certification review (e.g. under DO-178C, ISO 26262, ECSS, etc.)?
• Any technical concerns or supporting evidence I may have missed?

No rush - just looking for informed perspective. Thank you.

[felix91gr]

Context: this is about the following thread in rust-internals that was in the OP at some point: https://internals.rust-lang.org/t/idea-pre-rfc-null-free-pointer-and-zeroable-reference/23991

Okay, I'm up to Feb 12 on the thread, and what else can I say but to reaffirm what many there have already said. You're getting answers from some of the most knowledgeable folks in the community. In particular, I'll say that what theemathas, bjorn3, CAD97 (even if they're a bit strongly-worded about it), josh and scottmcm say is pretty much spot on.

Edit: Oh, Ralf has also added his 2c to this. There might not be a human with more understanding of the low-level memory semantics of Rust than him.

[felix91gr]

Okay, I've read it through. I think the consensus is clear - field projections with volatile should complete the feature set required for covering your use case in pure Rust. I don't see a future in which field projections aren't eventually finished and stable, so if you ask me, you will eventually have all of the pieces you'd need.

In your experience, would reliance on inline assembly or volatile workarounds to access address 0x0 pose issues during certification review

In the case of Rust, you'd have to justify why you need to do so (which I think you've already done well).

But then you'd also have to prove (or convince the auditors) that the API you expose from your assembly code, is safe to call from elsewhere your system. Safe here meaning it doesn't have UB.

Doing such a proof is not a trivial effort by any means, but I don't see how an auditor would have qualms with such a solution, if you were able to prove to them that your assembly is correct.

[H4n-uL]

@felix91gr

Thank you for reading through the thread. The Internals discussion served its purpose during the early iterations, but the proposal has been substantially revised since - the current version supersedes it entirely and addresses both points you've raised.

On field projections and volatile: Please refer to Workaround is impossible - The &T chain, and Field projections + reborrow + arbitrary self types.

On assembly and certification: Please refer to Workaround is impossible - Runtime branching (volatile / inline assembly / double API) - Certification compliance, and Feasibility - Safety standards require defined semantics - not workarounds.

The full proposal is here: https://universet-uendelege.notion.site/Dereferenceable-Zero-322fb761f47480a5a825f12bc081bbf8

I'd value your perspective after reading through it.

[felix91gr]

I wonder how crazy would it be to work in a different address space, in the abstract machine sense.

To offset the address set by 1 ahead, such that:

• In code, the lowest useable address is written as 0x1.
• After compilation, all addresses 0xN are mapped to the address 0xN-1 in hardware.
• The null pointer, 0x0 in code, is mapped to the last address of the address space.

There's probably something obvious why this doesn't work. But I have to ask if it makes sense. It would allow you to use the 0x0 address in hardware, at least.

But again, there's probably something obvious that I'm missing.

[H4n-uL]

This is a creative idea, but I see three issues with this approach:

1. C FFI breaks immediately - all external addresses are off by one, and every hardware datasheet, driver, and debugger assumes physical addresses.
2. Even if FFI were somehow resolved, the cognitive overhead of 'every address in code is hardware address plus one' propagates through every layer of the system.
3. Even if both were resolved, this doesn't satisfy the certification question. An auditor reviewing under DO-178C or ISO 26262 would ask: "Ada has a native support To_Address(0), why did you choose Rust over Ada/SPARK?"

[felix91gr]

Even if FFI were somehow resolved, the cognitive overhead of 'every address in code is hardware address plus one' propagates through every layer of the system.

I mean, that's part of the point of address spaces, is it not? To be able to think about addresses in a way that makes sense for your use case, without needing to know about the details of the hardware.

C FFI breaks immediately - all external addresses are off by one, and every hardware datasheet, driver, and debugger assumes physical addresses.

I thought you were running in a heavily constrained system. Will you need to use FFI with anything in there?

In any case, this would be an abstraction you'd remove at compile time. Your binary would act as if its addresses had always started at 0x0

The C subsystems could call your ABI as long as you were very clear with the convention you're keeping.

An auditor reviewing under DO-178C or ISO 26262 would ask: "Ada has a native support To_Address(0), why did you choose Rust over Ada/SPARK?"

I don't know; why did you? That's something you have to answer. I cannot help you figure that part out :) you know why it is that you do the things that you do.

[H4n-uL]

@davidtwco
@PLeVasseur
@skade
@pellico
@darkwisebear

I'd like to hear some practitioners' perspective. No rush, but if it'll take more than a week, please let me know the timeline :) (so I can sleep at night instead of refresh-spamming gh issue at 4 a.m.)

[H4n-uL]

Note: The proposal has been revised - the previous dual-proposal structure (Proposal A/B) has been consolidated into a single design after analysis showed that changing &T's validity invariant is impossible as coreis also a crate. Please refer to The proposal - FAQ section.

[felix91gr]

Look, @H4n-uL, I'm going to be honest with you.

I think your proposal, as it currently stands, requires not a re-write, but going back to the design stage and evaluating the things that folks in the thread have told you.

I trust the criteria of every person I mentioned above, and in particular I trust Josh's, who gave a thorough re-read of your proposal and answered thusly:

• Your proposal is incorrect, and contains multiple things that you've specifically received corrections for.
• you are responding (...) continuing to try to push one idea you're set on, rather than reconsidering.
• Rust can address your use case, and people here are trying to help you address your use case. But Rust isn't going to make it look exactly the same as every other bit of Rust code, or allow you to reuse other bits of unsuspecting Rust code that (correctly) relies on guarantees Rust currently makes.
• No, it isn't [a single line change on the compiler], and you've been told this repeatedly. We're not making a change that penalizes every other program for the sake of this niche use case.

Furthermore, I believe what Frank said right after to be correct:

This thread has already provided a significant amount of time and feedback from several of our most experienced project members and regular language-design contributors. The newly updated proposal contains a section that still debates the possibility of re-defining the meaning of &T, an endeavor that would, as far as I can tell, be comparable in nature to some examples listed in Frequently Requested Changes - The Rust Language Design Team, and thus generally comes with the expectation that such a request should be “making an extraordinary case for why their proposal outweighs [known concerns]”, yet apparently the newly updated document doesn’t even appear to address several concerns already directly raised to the author.

And for the same reasons as Frank's, I think it's best to close this issue. I'll be pinging the mods.

[PLeVasseur]

Reflecting my comments from the Zulip thread over here too:

---

Hi there @H4n-uL 👋 after having looked through the proposal it seems like you're trying to address a problem, yep, and this is handled differently / genuinely better in e.g. Ada.

However, this seems to be working "against the grain" of the Project if you ask me; from what I can tell there's been a pretty consistent push-back on the mechanism that's been explained in the thread.

Looking over the linked document this doesn't seem to fundamentally change what I wrote above.

Seems to be outside our wheelhouse here in the SCRC, frankly.
I don't think I have much more to say on this point.

Marking this as close as not planned currently.