Since Windows never supported this unusual 32/64-bit hybrid, it will have no impact on WINE.

It's actually kind of a cool idea, though. To someone like me who grew up on 8-bit and 16-bit architectures and is regularly taken aback at the size of data structures on 64-bit platforms -- 16 bytes just for a pointer and a length? -- being able to cut those down while still being able to run at full speed [*] on modern hardware sounds really useful.

[*] Assuming it's really full speed. I suspect there's some overhead.

Sure, if you want to run a system with hundreds of known vulnerabilities. Better keep it airgapped.

Er, actually, the above is incorrect and was a result of my contrived test example. With the real data structures there is no risk of anyone moving them because the code that creates them returns *only* a &'static mut. Effectively, no stack frame ever has ownership of the structures, so there is no risk of them being moved. This is all pretty obvious, actually, and essentially necessary. If there is no heap then everything is either stack-based or something akin to a global.

I checked and, indeed, trying to "move" the "hashmap" generates code to copy enough stuff onto the stack to blow it. I'm going to look into using Pin to let the compiler know that none of that stuff is moveable. Thanks!

Yeah, so you apparently missed that I have no heap and the "hashmap" isn't actually a hashmap... and it's actually in the same not-really-moveable space as the data it holds. It would be interesting to look into what would happen if I tried to move it; I think the compiler doesn't actually know that it's not moveable and would generate code to copy it to the stack. That would be more expensive than copying the "contained" data item, since it actually owns its lookup tables by value, rather than holding pointers to heap allocated structure.

As I said, your big-system biased intuitions don't really hold here.

Moving something out of a hashmap and then back into it isn't cheap. I mean, both operations are O(1), but that's amortized and hides significant overhead. I think it's well worth returning a &mut to avoid that, even in the common, std case. In the my noalloc case, it's considerably more complicated than that: The referenced memory isn't really moveable (and it's not really a hashmap). In practice, it would be "copy the data to the stack, leaving the original in-place, then make sure to copy the mutated version back to the original location". The stack consumption of that approach would be worrisome.

This is where the big-system biases of some of the Rust community work against it, and what fuels the certainty of C programmers that C is the right language for tiny devices. In C there would be no question -- you'd just look up the data in the map and return a pointer to it. Very efficient, no needless waste of several hundred bytes of precious stack space or any need to find some other memory region to copy it into. You say that "moves in Rust are cheap" but whether that's true is extremely context-dependent, and it's basically always the case that a pointer is even cheaper.

Unfortunately, the risks of the C approach are very well-understood, and my point in the post with which I entered this discussion was that Rust can be just as good for space and cycle-efficient low-level code as C while also providing significant security and safety benefits. Your arguments would seem to undermine my point about Rust's utility, except that your big-system biases are not, in fact, universal in the Rust ecosystem. There are plenty of people who understand the constraints of writing code on a device with 64K total RAM and a 1K stack who are writing Rust code and ensuring that the language is a good fit.

Not insane at all, just uninterested in the well-being of anyone other than himself.

If this happens, Trump will end up being in charge of deciding which companies get the plutonium, and those that do the best job of making Trump feel, er, appreciated, will get the nod. Also, I expect Trump to address safety concerns by setting up a multi-billion dollar fund of taxpayer money to address any necessary cleanups or other issues, a fund that is under his sole ultimate control, without congressional or any other oversight (c.f. Venezuela oil fund, "anti-weaponization fund", etc.). Maybe it'll have confidential quarterly reports issued to the NRC's board of directors (which is traditionally independent but now thoroughly controlled by Trump thanks to SCOTUS' allowing Trump to fire anyone in the executive branch and Trump's immediate action to fire Christopher Hanson as chair of the NRC board and replace him with a lapdog).

To be fair, it arguably should always had had that disclaimer. They avoiding needing it by saying they were just providing links and it was on those web sites and their users to deal with any inaccuracies... but everyone knew that most users just took whatever the top link said as definitive truth.

True. So a smallish (though big enough to produce a visible shockwave that expanded for at least hundreds of meters) detonation followed by a much larger deflagration, perhaps.

Hmm. I think you misunderstood the problem (possibly I over-simplified the toy version). In your "works" function, you're evicting an already-evicted entry? What? Also, you're still doing two map lookups, so you've (a) used my two-lookup solution (b) violated encapsulation by exposing the evict function and (c) returned a weird error to the caller... you're telling the caller you couldn't find their item to evict, when they were trying to retrieve something not evict something.

As for not mutating in a match guard, the mutation is an internal detail, not part of the public interface.

Yes, this argues for maybe using a RefCell for internal mutability to avoid the semantically-inaccurate exposure of that internal mutation through the &mut self on recently_evicted(). That's a valid point and a better solution. I should probably get more comfortable with RefCell; for some reason the concept rubs me the wrong way, though I don't have any problem with the comparable C++ construct (a mutable field).

Another option is to forgo the optimization of removing the already-reported eviction record from recently_evicted. This isn't just a performance optimization, though, it's to maximize the number of callers who are informed about why their attempted operation failed while keeping the space strictly bounded (it's not actually a Vec in the real code, nor is the HashMap a std::HashMap -- this code runs on a tiny microcontroller with no heap). There's quite a bit more to it than my very-simplified example showed -- but every way of doing it requires mutating the recently_evicted record.

As for the comments about not returning &mut, the other option is to remove and re-add the entry on every usage, which is far worse than searching the map twice. `get_mut()` is not evil. It exists for very good reasons.

I've been searching for that estimate but haven't found it. Do you have the source?

There was definitely an expanding bubble that looked exactly like a shock wave. I have no idea if there might be something else that it could be, but it looked like a shock wave to me.

Indeed. I'm currently working in the automotive space, where there are lots of tiny embedded controllers to mange everything from engine operations to taillight flashing... and it's almost entirely C++. There's a little C in some pockets, but even then it's generally (a) built with a C++ compiler, and (b) has at least some actual C++ in it, even if it's C, stylistically.

Rust is a great fit, and a big improvement over all of the extra processes that try to paper over C++'s weaknesses when trying to write guaranteed-reliable code (C++ is better than C in that regard). The problem is that we can't actually use Rust in any safety-critical contexts -- even though it's clearly fantastic for those cases! -- because the necessary ASIL certifications are lacking. There are people working on it, though. Maybe it's actually solved... I need to look into the Ferrocene solution and see what it includes and what it will cost us. I strongly suspect that Ferrocene's compiler and libs are completely unmodified copies of the regular Rust toolset, and that what you're paying for is just their certification work. But that's probably just fine... the work needs to be done and someone needs to be paid for it.

In this case, the answer is better tools, meaning better than C. There is fundamentally no way to get memory safety in C. People have been trying for decades with smarter linters, macros, manual review processes... nothing works at scale. If you have a solution, you should show it to the world and become rich and famous.

Give it a try! See if you can find a solution that I couldn't.

The gist contains a hugely-simplified version of the code, of course but enough to show the problem, in multiple variations. I actually tried a lot of other things, including adding some helper functions but, no matter what, if I have a codepath that returns a mutable ref to the content, the mutable borrow of self is held until the end of the function so nothing else can borrow. The only workable solutions I found were (a) double lookup or (b) unsafe code that creates an additional mutable reference.