Simple: we don't want some low level kernel memory management dictating what constitutes an "object".
Everything isn't object-oriented. E.g. large arrays, memory-mapped files, including executables and libraries.
Linear memory sucks, but every other organization sucks more.
Segmented has been done; the benefit-to-clunk ratio was negligible.
Of course, there are probably lots of in-practice exceptions when it comes to embedded, kernel code, mmap() shenanigans, etc.
This is an extremely simplified and probably incorrect view of https://open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1434r0.... This is complicated because nobody agrees on what the correct behaviour should be, and we have mountains of legacy codebases that all rely on something slightly different when pointers get converted to ints and back.
Rational built a truly semantic IDE, and the result of that is that if you change a line of source-code somewhere in a huge complicated project, it will know precisely what the consequences of that change are.
Ultimately, this allows it often just recompile that single line.
I love the approach, it's a way to get a lot more memory safety while not giving up a program's flexibility, especially in C's case.
Some languages are opting to disallow pointer arithmetic and conversion between integers and pointers. We'll see how it works out!
[0] https://verdagon.dev/blog/generational-references
[1] https://developer.arm.com/-/media/Arm%20Developer%20Communit...
"hey you allocated it you should know about it right?" right yeah
In C++, I think they added enough magic in that you should now be able to do it (placement new, std::launder and numerous other hacks).
My understanding that reusing the storage would violate the aliasing rules[1] and the rules against overlapping object lifetimes.
[1] while char ptrs can be used to access everything, the reverse is not allowed.
> Attribute malloc indicates that a function is malloc-like, i.e., that the pointer P returned by the function cannot alias any other pointer valid when the function returns, and moreover no pointers to valid objects occur in any storage addressed by P. In addition, the GCC predicts that a function with the attribute returns non-null in most cases.
But it doesn't provide any operations to do the things in this paragraph (create new pointers). The operation that does this is malloc itself.
This will typically not cause problems, but it would if LTO got so good you could include libc in it.
Olde C used to just let you use integers as struct pointers, and there was only one struct member namespace. so code like this was valid and did an integer-size write to address 0177770. old unix did this for device register access; see the lions book.
struct { int integ; };
f() { 0177770->integ = 012345; }
That doesn't mean we need a memory model in which bits are separate objects, in some sense.
( one reference to thunks involving segmented memory: https://devblogs.microsoft.com/oldnewthing/20080207-00/?p=23... )
The problem was mainly caused by having no MMU, so moving around objects in order to save space required adjusting pointers. Today, a copying garbage collector will do the same thing; rewrite all the links among the moved objects. You'd have similar hacks on Apple Macintoshes, with their MC68K processors and flat space, like doubly indirected objeccts managed by "handles" and whatnot.
Here is a somewhat reasonable diagram of how it all works
https://stackoverflow.com/questions/4039325/assembly-segment...
(although i'm probably agreeing with you)
One pain point in 16-bit Windows programming was that you had to do two special things for any callback function in your application: EXPORT the function in your .DEF file, and call MakeProcInstance() on your callback function to get an "instance thunk".
FixDS made a simple patch to the compiled function prologs that rendered all of this unnecessary. You could just use your callback function directly, like we expect today.