3 ms·
The pointer is invalidated only if the object is moved and the object is not always moved and hence the pointer is not always invalidated. http://pubs.opengrou
by mhogomchungu 11y ago
The pointer is invalidated only if the object is moved and the object is not always moved and hence the pointer is not always invalidated.
http://pubs.opengroup.org/onlinepubs/7908799/xsh/realloc.html http://pubs.opengroup.org/onlinepubs/7908799/xsh/realloc.htm...
- derefr 11y agoDo note that I wasn't proposing to invalidate the memory-address handle contained in p; but rather to lexically invalidate p itself, such that it would no longer be legal for it to occur as an rvalue until a new value was assigned to it as an lvalue. You know, like Rust.
- shultays 11y agoIn this case it is easy to see that p is no longer valid but what about other pointers that points to the same location but not trivially visible for compilers? It won't be possible without run time checks or memory system like the one in rust.
- lmm 11y ago> It won't be possible without run time checks or memory system like the one in rust. So do that then.
- shultays 11y agorun time checks are run time checks, they add overhead. (imho) dangling pointers not worth the crippling the language like rust does.
- pcwalton 11y agoI've written hundreds of thousands of lines of working code in the "crippled" language you're referring to. And dangling pointers result in use-after-free, which frequently results in remote code execution vulnerabilities. Do you have a practical alternative to eliminating those RCE vulnerabilities, or should we accept them? To be clear, your position is an intellectually coherent one to take. But we should be clear about its implications.
- ben0x539 11y agoIsn't servo, which I assume where most of your Rust code lives by now, trading some safety to un-"cripple" Rust by having GC-backed smart pointers that allow for uses-after-free if they aren't used correctly?
- kibwen 11y agoServo integrates with a GC not because Rust is insufficiently expressive, but because it has to cooperatively manage the DOM with a garbage-collecting Javascript engine.
- pcwalton 11y agoAbsolutely not, for several reasons: - The reason why we use GC pointers in Servo is that JavaScript is garbage collected, and we can't do anything about that. If not for that, we probably wouldn't use GC at all. - In fact, to prove this point, we don't use GC anywhere except the DOM. Most of my code is layout and rendering, which is GC-free, written in the safe language, and is very much not crippled in any way. - GC pointers are designed to be safe. There are some known safety holes right now, mainly due to lack of time to plug them and wanting to balance the time spent to fix up the current system against the time needed to add proper GC support to Rust.
- Rusky 11y agoHow is Rust crippled by affine types? From my perspective it simultaneously eliminates bugs and enables new techniques.
- pdw 11y agoThat's not how I interpret that. Both the specification of malloc() and realloc() contain this phrase: > The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object and then used to access such an object in the space allocated (until the space is explicitly freed or reallocated). (Emphasis added.) After realloc() succeeds, you can no longer use the original pointer.