Does pinning an object guarantee that the hexadecimal memory address stays constant?

Sweet and simple, the title is

As long as you don’t use unsafe yes. If you do use unsafe, then you must uphold this guarantee as well as the others listed in the pin docs

1 Like

Right, okay. As an example, let’s say you’re in an unsafe block and want to purposely change the address. What is one way you might do that?

You shouldn’t, that would be UB. For example, say the pointee is an immovable type. If you want to allow addresses to change, don’t use pin.

Let’s say I have a reference, &R, to a sector in memory at 0x0000… which has an owner, R, in a parallel thread. I use an unsafe to dereference *&R => R. Let’s suppose nothing is happening is the owner’s parallel thread. Okay, so the question is: When I dereference &R => *&R <==> R to clone some value in R, does R temporarily move for a few nanoseconds inside the unsafe block during the clone process? Or, how does that play out?

(above is slightly unrelated, but still relevant in terms of learning)

It’s not really a question of whether R “moves”; it’s a question of whether you’ve momentarily, at one point in your code, released the compiler from it’s obligation to not optimize your code into random behavior. That’s what UB does: it abrogates the programmer’s contract with the compiler. Or to summarize in a phrase that most programmers know well: garbage-in garbage-out.

Thanks for the reply. Might you have a good “pointer” towards an article that helps develop understanding of what’s happening at the level I’m contemplating?

This concurrent thread in IRLO may be a good start. There are many others. Unfortunately “UB” is too short a word to be searchable on the Rust forums, but any post that discusses UB is likely to be educational, particularly if one of the contributors is @RalfJung.


Perhaps the spirituality in coding is surrendering to the unknown in the undefinedness of UB-land. Only in suffering (i.e., trial/error io) does one grow understanding. But on a more serious note, I created system of formal logic that is based on modal logic, and would like to implement it using rust. It deals with self-referential systems and intercommunication of nodes with shared data. It required knowledge of linear algebra, discrete math, and of course standard mathematical logic. Now the hobby is to implement it, but one must first know the low-levels to match the low-level that is an axiomatic system.

You might appreciate these Rust koans. Also, as you learn Rust, this periodic table of Rust types may be of help.

1 Like

The only thing that I would change about the periodic table is, instead of immutable it should be shared and instead of mutable it should be unique. This better reflects how the compiler thinks of these types and explains the standard library better than thinking in terms of mutability.

For more reading about this,

Link to RalfJung’s blog

1 Like

Right, because unlike C++ or virtually every other language, mutable types are unique. This is really great for optimizing of course. It forces the thinker behind the keyboard to create optimized code via algorithms. Kind of like noether’s theorem (i.e., reducing the input dimensions but get the same effective output, thus less computation), but applied to CS


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.