Hacker News Reader

Comment by hdhrufjdi | Hacker News Reader

A 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-...

PS: small overhead is technically still overhead; yet, I am not saying you should worry about it

View on HN

Yes, 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.

Rust could avoid it through the Box abstraction that afaik assumes not having a nullptr

It would not. Rust needs ASAN/UBSAN/TSAN/MSAN sanitizers for a reason.

Can you point me to any significant primarily rust codebase that runs sanitizers? I've never heard of that. Unless you mean miri.

Not 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

[2] https://doc.rust-lang.org/unstable-book/compiler-flags/sanit...

No idea what is your point.

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?

Reply on news.ycombinator.com