3 ms·

> I don't think there are any general purpose programming languages with decent performance which outright "prevent undefined behaviour" in something like NSS.

> I don't think there are any general purpose programming languages with decent performance which outright "prevent undefined behaviour" in something like NSS. Rust, for example, does not. You know what I meant by "a language that prevents UB". Your comment argues semantics. That's not nice. Please stop. > safe Rust doesn't have undefined behaviour but of course you can (and a large project like this will) use unsafe Rust and then you need the same precautions for that code. How can that can be true? A large Rust project uses unsafe only because its authors don't care enough. Instead of spending the effort to make the safe code fast enough, they resort to using `unsafe`. It's the same reason that people add code without tests or add APIs without docs. A special purpose language for writing cryptography code is a terrible idea. Once we have a language suitable for handling untrusted data, we should make it good enough to use for everything and then use it for everything. I have put some effort into making safe Rust usable for everything. I wrote a safe regex library [0] and a safe async library [1]. I plan to put more effort into these and other libraries. For example, I am working on safe Rust TLS and HTTP libraries. Eventually, safe Rust will be production quality and fast enough for most use-cases. [0] https://crates.io/crates/safe-regex https://crates.io/crates/safe-regex [1] https://crates.io/crates/safina https://crates.io/crates/safina

burntsushi 5y ago
> A large Rust project uses unsafe only because its authors don't care enough. This is not true. That might account for some aspects of why there are some uses of 'unsafe', but it is not true of all uses of 'unsafe'. The existence of 'unsafe' is itself the clearest demonstration of why you're wrong on this point. Its existence is a practical trade off that acknowledges it is sometimes necessary to use 'unsafe' to accomplish some goal, and that there is a long tail of such uses. Too long to feasibly build and enumerate every such case into the language. The goals might be rooted in functionality or performance or possibly other things.
dralley 5y ago
> A large Rust project uses unsafe only because its authors don't care enough. This is not true at all. There are plenty of reasons to occasionally use unsafe code, even if your bar for "is it really worth it" is quite high. One reason, if you're writing a crypto library, is that certain kinds of timing attacks are pretty much impossible to prevent without inline assembly.
- mleonhard 5y ago
  Preventing timing leaks requires unsafe code because the Rust compiler lacks support for constant-runtime code [0]. Adding that support is one step in making it "good enough to use for everything". What are several more of the "plenty of reasons to occasionally use unsafe code"? I can think of only one: interfacing with hardware or unsafe OSes that control access to the hardware. [0] https://github.com/rust-lang/rfcs/issues/2533 https://github.com/rust-lang/rfcs/issues/2533

burntsushi 5y ago

> A large Rust project uses unsafe only because its authors don't care enough. This is not true. That might account for some aspects of why there are some uses of 'unsafe', but it is not true of all uses of 'unsafe'. The existence of 'unsafe' is itself the clearest demonstration of why you're wrong on this point. Its existence is a practical trade off that acknowledges it is sometimes necessary to use 'unsafe' to accomplish some goal, and that there is a long tail of such uses. Too long to feasibly build and enumerate every such case into the language. The goals might be rooted in functionality or performance or possibly other things.

dralley 5y ago

> A large Rust project uses unsafe only because its authors don't care enough. This is not true at all. There are plenty of reasons to occasionally use unsafe code, even if your bar for "is it really worth it" is quite high. One reason, if you're writing a crypto library, is that certain kinds of timing attacks are pretty much impossible to prevent without inline assembly.

mleonhard 5y ago
Preventing timing leaks requires unsafe code because the Rust compiler lacks support for constant-runtime code [0]. Adding that support is one step in making it "good enough to use for everything". What are several more of the "plenty of reasons to occasionally use unsafe code"? I can think of only one: interfacing with hardware or unsafe OSes that control access to the hardware. [0] https://github.com/rust-lang/rfcs/issues/2533 https://github.com/rust-lang/rfcs/issues/2533