Stack overflow says "delete" would check for null before deallocation: https://stackoverflow.com/questions/4190703/is-it-safe-to-de...
Happy to be educated
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.
PS: small overhead is technically still overhead; yet, I am not saying you should worry about it
Overhead is almost purely theoretical and it cannot be avoided and is not anything common or specific to unique_ptr's.
> 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
[2] https://doc.rust-lang.org/unstable-book/compiler-flags/sanit...
The compiler is happy to compile without sanitizers enabled. Why should it require to implement a null check when deallocating when it doesn't when dereferencing?
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().