[steveklabnik]

> Of course they have. It's a basic set of machine code instructions. Can you specify which doesn't please?

That they exist is not the problem. That they exist _and_ don't provide enough performance is the issue. That is, your "no cost" is what I'm asserting here, not that it doesn't exist at all.

(This is not my area of specialty but was brought up when discussing this behavior; it's measured as a 20%-100% hit to speed, which is unacceptable.)

> Do you honestly think a project like curl has everything it needs "which needs a lot of unsafe" already implemented in the current standard libraries?

I don't think a project like curl needs much (if any) unsafe.

> Why don't you rewrite the curl in Rust then, it's just using what's already written? Let me know how far you come.

I did not suggest that curl should be re-written in Rust. I do think a functional equivalent in Rust would be good to have. I do not have the time to write such a thing myself. Luckily, many others have been working on this kind of thing.

> does curl still have to use a Rust wrapper around openssl,

ring is a port of BoringSSL to Rust, piecemeal. It still has some C code today, but at the end, will be all Rust/asm. Given that BoringSSL is a fork of OpenSSL, I would imagine that it would have enough functionality.

[acqq]

> That they exist is not the problem. That they exist _and_ don't provide enough performance is the issue. That is, your "no cost" is what I'm asserting here, not that it doesn't exist at all.

I'm claiming that the machine instructions exist to implement at no cost this high level construct (using C-like syntax):

    if ( overflows( c = a + b ) ) {
    }

What people say to produce slowdowns is if they want to implement

     try {
          a huge bunch of instructions where some are additions
     }
     on integer_overflow_from_wherever do whatever

The former is no cost if implemented, and exists in every CPU. The later doesn't exist, but who says that only later is what has to exist? Why not implementing the no-cost former?

> It still has some C code today

Exactly my point why curl has no reason to be reimplemented in Rust now.

[steveklabnik]

> I'm claiming that

This is different than the claims that were made when we made this decision. Specifically, the cost angle. You can absolutely do this, but we don't turn it on by default due to its expense. See https://danluu.com/integer-overflow/ for example. From that link:

> Summing up, integer overflow checks ought to cost a few percent on typical integer-heavy workloads

That few percent matters. And the extensive discussion (in both directions) on HN: https://news.ycombinator.com/item?id=8765714

It would be reasonable to turn it on, but that's not the decision we made.

> Exactly my point why curl has no reason to be reimplemented in Rust now.

Again, I never said curl should be ported to Rust.

[dbaupp]

FWIW, the former "no-cost" thing does exist in Rust, in the form of "checked_..." methods on the various integer types, e.g. https://doc.rust-lang.org/std/primitive.i32.html#method.chec... .

[acqq]

Thanks! That's the good approach.