I definitely remember casting pointers to ints and printing them to prove to myself what it was pointing to and what the offset was for the next value e.g. in an array.
In C you can also do those fun array indexing and pointer arithmetic tricks that require you truly understand the concept of "address plus offset" that basically everything uses.
But even if that's a hallucination, Rust does the hard work of keeping pointers off your mind by a combo of refs, box, etc. and Rust is not a good first language, I don't think, for a variety of reasons.
My ultimate programing curriculum if I had to make one would teach you to program in python, then show you C via Cython or similar. Lots of allocation and free under the hood in Python.
Casting pointers to ints is generally safe (at least as long as you use intptr_t instead of assuming that the size of pointers will never change).
The issue comes when you try casting to pointers. Because of providence, aliasing rules, and a couple of dragons that built a nest in the C language specification, you could have two pointers to the exact same memory locations, but have the program be undefined if you use the wrong pointer.
Granted, this doesn't stop you from doing things like
foo_t *foo = (foo_t*) 0xDEADBEEF
And in the few occasions where that is something you would reasonably want to do it does more or less what you would expect (unless you forgot that the CPU sticks a transparent cache between you and the memory bus; but not even assembly would save you from that oversight).
Provenance (outside programming this is the distinction between "I reckon this old table is a few hundred years old" and "Here is the bill of sale from when my grandfathers ancestors had the table made from the old tree where that cherry tree is now in 1620") not Providence.
In Rust pointer provenance is a well defined language feature and if you go to the language docs you can read how it interacts with your use of raw pointers and the twin APIs provided for this.
In C the main ISO document just says basically here be dragons. There's an additional TS from 2023 with better explanation, but of course your C compiler even if it implemented all of C23 needn't necessarily implement that TS. Also of course the API is naturally nowhere near as rich as Rust's. C is not a language where pointers have an "addr" method so they also don't need a separate exposure API.
I suspect that in Zig none of this is clearly specified.
Sure, I'm interested in whether any of those bugs affect say, Cranelift because the Cranelift did, as I understand it, a much better job of coming up with a coherent IR semantic so unlike LLVM fixing bugs in this layer isn't as scary if it's necessary for them.
It is definitely possible to write Rust or (with more difficulty, legal C) which should show off something about provenance semantics and instead the LLVM backend just emits contradictory "One and two are the same number" type nonsense code. In C of course they can say well, since the ISO document pointedly does not specify how this works, maybe one and two really are the same number, although nobody actually wants that - in Rust that's definitely a bug but you will just get pointed at the corresponding LLVM bug for this issue, they know it's busted but it's hard to fix.
I don't know whether fixing the LLVM bug magically makes it TS6010 compliant. If so that would be nice.
In systems languages that predated C like NEWP and PL/I variants, in Object Pascal, Modula-2, Mesa, BASIC, Ada.
The different is that some of them have the knowledge between type safe pointers, i.e. can only be created by taking adresses of existing variables, and unsafe pointers, i.e. can be created out thin air like in C.
