5 ms·
Just a thought: null pointer check before deallocation
by hdhrufjdi 4y ago
Just a thought: null pointer check before deallocation
- gpderetta 4y agodelete of a null pointer is well defined.
- menaerus 4y agoAside from you being completely uninformed because free(nullptr) or, for that matter, delete nullptr does absolutely nothing and is well defined operation so you don't need to check for that condition in the first place. But even if you had to, what implications would it have, if you care to explain?
- hdhrufjdi 4y agoThe implications would be checking if it is null before performing the deallocation of the memory, which is a runtime overhead. Stack overflow says "delete" would check for null before deallocation: https://stackoverflow.com/questions/4190703/is-it-safe-to-delete-a-null-pointer https://stackoverflow.com/questions/4190703/is-it-safe-to-de... Happy to be educated
- menaerus 4y agoExtra branch which is going to be taken 99.99999% of the time is not going to present any runtime overhead. CPU BP unit handles it for us. That said, if this really had been an overhead, virtually every language out there would suffer from it, including Rust. Every language out there at some point needs to call into the libc.
- hdhrufjdi 4y agoA bit of research revealed that you don't have to call into libc. You may use alternatives or even use sys calls directly, like Go apparently did: https://stackoverflow.com/questions/41720090/does-go-depend-on-c-runtime https://stackoverflow.com/questions/41720090/does-go-depend-... PS: small overhead is technically still overhead; yet, I am not saying you should worry about it
- menaerus 4y agoYes, you can write your own runtime ... which will have to rely on the OS internals to do any meaningful work, and in case of memory allocation or deallocation it will have to rely on brk/mmap and then you will be back to square one. Overhead is almost purely theoretical and it cannot be avoided and is not anything common or specific to unique_ptr's.
- hdhrufjdi 4y agoRust could avoid it through the Box abstraction that afaik assumes not having a nullptr
- menaerus 4y agoIt would not. Rust needs ASAN/UBSAN/TSAN/MSAN sanitizers for a reason.
- iudqnolq 4y agoCan you point me to any significant primarily rust codebase that runs sanitizers? I've never heard of that. Unless you mean miri.
- menaerus 4y agoNot miri. I mean the actual ASAN, UBSAN, TSAN, MSAN and LSAN sanitizers that are also commonly used in C and C++ codebases. Descendant is the same: LLVM [1] > Can you point me to any significant primarily rust codebase that runs sanitizers? I've never heard of that Not sure what do you mean by that, surely there are. At least the ones who are serious about the development. Sanitizers are part of official documentation in Rust [2]. [1] https://github.com/rust-lang/rust/issues/39699 https://github.com/rust-lang/rust/issues/39699 [2] https://doc.rust-lang.org/unstable-book/compiler-flags/sanitizer.html#sanitizer https://doc.rust-lang.org/unstable-book/compiler-flags/sanit...
- 4y ago
- simiones 4y agoWhile I agree with your point overall, it's important to note that libc is definitely not a must on some platforms. On Linux in particular, the Kernel user-space ABI is stable, so you can write your own system calls in whatever language you want. Also, even if you chose to use some libc for system calls, there is no reason to use malloc()/free(). You only need mmap() or similar, and then your own language runtime can write their own user-space memory manager. As a side-note, on Windows, libc isn't even a system library. The official way to execute system calls is using win32, and things like malloc()/free() are simply wrappers around HeapAlloc() and HeapFree().