>>106979781
This is the issue with the rustroons lack of understanding of memory safety. "In" and "out" of bounds depends on which set of bounds you're talking about. When malloc mmaps in memory, it is allowed to access any byte of that memory. But when it hands some of that memory to a subsystem, the subsystem is only allowed to access the bytes that are part of the allocation. The bytes are "in" bounds for malloc, but "out" of bounds to the subsystem. So too with any system with respect to it's subsystems.
I'm really only explaining this to the peanut gallery, because the rustroons will never be able to wrap their heads around this. They will, with zero self awareness or irony, write a custom allocator in order to circumvent the borrow checker, let use after frees and leaks pile up out the ass, then tell you with a straight face that it's all memory safe because the compiler said it was ok. They do not understand what is wrong with that and cannot be brought to understand.
I should mention something else. When official rust docs and the like claim to be able to prevent memory safety, they mean something very narrow: they can guarantee that a program will never segv. This is because, in safe rust, we cannot convert an int to a pointer, and we cannot generate pointers to invalid memory. While interesting, this is perfectly useless in the real world. If a program segvs, then it will cleanly crash and any crisis will be averted. The danger with "memory safety" in c is not crashing, it is subsystem A inadvertently accessing memory belonging to subsystem B. Rust cannot prevent this sort of unsafety, and should stop lying to people by pretending it can.
