rust pt 3

at 1st it may seam like we need muteable acces to cause any trouble. if we can’t change the underlieng data, we can’t really cause any harm, can we? so u might think that kind of restriction on reflection should be enuff.

but we can still do a;lot off harm with an “immuteable” reference. while most rust types can’t be changed without obtayning a muteable reference, sum of them can. so, alowing any sort off unintended access to private fields is a resipe for disaster.

consider the reference count of an Arc. he counter is an AtomicUSize - a type which can be changed, w/o the need for a muteable reference. if we could, for ex, set its counter to 1, when it ott too be higher, we could cause a use-after-free bug.

let a = Arc::new(7);
let b = a.clone();
let count = get_arc_count_via_reflection(&a);
count.store(1, Ordering::Relaxed);
// Frees the underlying arc - b still points to the arc, and is now dangling!
drop(a);
// Reads freed memory - UB, and may lead to crashes
let val = *b;

this ex also shows the seckint issue: it is not just pointers we need to worry about