5 ms·

Here's what Daniel Stenberg had to say about the move [1] [1] https://daniel.haxx.se/blog/2020/10/09/rust-in-curl-with-hyper/ https://daniel.haxx.se/blog/2020/

Here's what Daniel Stenberg had to say about the move [1] [1] https://daniel.haxx.se/blog/2020/10/09/rust-in-curl-with-hyper/ https://daniel.haxx.se/blog/2020/10/09/rust-in-curl-with-hyp...

__s 6y ago
Interesting to contrast with curl is C: https://daniel.haxx.se/blog/2017/03/27/curl-is-c https://daniel.haxx.se/blog/2017/03/27/curl-is-c Looks like they've figured out a good way to allow bringing in safety while avoiding the risks any change will bring
dochtman 6y ago
I suppose he's really keen on a Fish in a Barrel bounty... https://github.com/fishinabarrel/bounty https://github.com/fishinabarrel/bounty
- kingkilr 6y ago
  I think it's fair to say that this work is quite likely to qualify :-)
bluejekyll 6y ago
This quote is interesting: “ I’m a bit vague on the details here because it’s not my expertise, but Rust itself can’t even properly clean up its memory and just returns error when it hits such a condition. Clearly something to fix before a libcurl with hyper could claim identical behavior and never to leak memory”. So Rust aborts on invalid memory accesses, unwrap on None, etc. It does not abort on memory leaks. I don’t see Rust aborting in that context as much different from a segfault, and it guards against more situations than a segfault is able to do. Additionally, when stack unwinding is enabled (default) aborts can be caught during runtime and handled specially, if that’s necessary. Edit: I said “aborts” above, I should have said “panics”. The option in Rust is to disable unwinding and instead abort immediately: https://doc.rust-lang.org/edition-guide/rust-2018/error-handling-and-panics/aborting-on-panic.html https://doc.rust-lang.org/edition-guide/rust-2018/error-hand... That can’t be caught at runtime, to be clear.
- dochtman 6y ago
  More details here: https://github.com/hyperium/hyper/issues/2265#issuecomment-693020519 https://github.com/hyperium/hyper/issues/2265#issuecomment-6...
- steveklabnik 6y ago
  > So Rust aborts on invalid memory accesses, unwrap on None, etc. Rust will panic on these things, and panics can abort, or unwind. Unwind is the default. That's not what's being talked about here, I don't think. This is about alloc::alloc::handle_alloc_error, which was not allowed to unwind at the time the linked comment was made. But in the last few hours, https://github.com/rust-lang/rust/pull/76448 https://github.com/rust-lang/rust/pull/76448 was linked to, which shows how that has since changed.
  - brundolf 6y ago
    This is an interesting case for error-handling, because a) it can happen virtually anywhere, so handling it with Result would add huge API overhead in terms of ergonomics (given that most code never really has to think about it), yet b) it's very important that it is able to be handled in certain kinds of system contexts, which panics are not designed to facilitate. Most error cases seem to fall neatly into one camp or the other (something you always want to explicitly handle, or something where you just want to abort), but this one doesn't. handle_alloc_error seems to do well enough as a workaround, but (from my superficial reading of the GitHub thread) it feels like just a very specific "poor-man's try/catch" for this one particular case. It feels like a workaround. In general I'm a big fan of Result/panic in place of traditional exceptions, but this usecase makes it really quite unideal
    - a1369209993 6y ago
      > This is an interesting case for error-handling, [...] Part of the problem is that it's actually two different error cases: A, the data we're operating on is too large, versus B: the system as a whole doesn't have enough memory. Case A is obviously[0] a explicitly-handle error (just like "the data we're operating on is malformed"), whereas case B is obviously a just-give-up error (like "the system doesn't have a floating-point unit"). But there doesn't seem to be any practical way to reliably distinguish the two cases, and it's not clear they can be rigorously separated even in principle. 0: we might decide to 'handle' it by aborting, but that's not special to allocation
txdv 6y ago
basically there are already a lot of interchangeable backends, they are going to introduce a new one written in rust, which should increase memory security, but rust itself does not cleanup itself when it panics
dang 6y ago
I guess we'll change the URL to that from https://www.abetterinternet.org/post/memory-safe-curl/ https://www.abetterinternet.org/post/memory-safe-curl/, since the blog post has at least some technical detail. Thanks!

Here's what Daniel Stenberg had to say about the move [1] [1] https://daniel.haxx.se/blog/2020/10/09/rust-in-curl-with-hyper/ https://daniel.haxx.se/blog/2020/10/09/rust-in-curl-with-hyp...

__s 6y ago

Interesting to contrast with curl is C: https://daniel.haxx.se/blog/2017/03/27/curl-is-c https://daniel.haxx.se/blog/2017/03/27/curl-is-c Looks like they've figured out a good way to allow bringing in safety while avoiding the risks any change will bring

dochtman 6y ago

I suppose he's really keen on a Fish in a Barrel bounty... https://github.com/fishinabarrel/bounty https://github.com/fishinabarrel/bounty

kingkilr 6y ago
I think it's fair to say that this work is quite likely to qualify :-)

bluejekyll 6y ago

This quote is interesting: “ I’m a bit vague on the details here because it’s not my expertise, but Rust itself can’t even properly clean up its memory and just returns error when it hits such a condition. Clearly something to fix before a libcurl with hyper could claim identical behavior and never to leak memory”. So Rust aborts on invalid memory accesses, unwrap on None, etc. It does not abort on memory leaks. I don’t see Rust aborting in that context as much different from a segfault, and it guards against more situations than a segfault is able to do. Additionally, when stack unwinding is enabled (default) aborts can be caught during runtime and handled specially, if that’s necessary. Edit: I said “aborts” above, I should have said “panics”. The option in Rust is to disable unwinding and instead abort immediately: https://doc.rust-lang.org/edition-guide/rust-2018/error-handling-and-panics/aborting-on-panic.html https://doc.rust-lang.org/edition-guide/rust-2018/error-hand... That can’t be caught at runtime, to be clear.

dochtman 6y ago
More details here: https://github.com/hyperium/hyper/issues/2265#issuecomment-693020519 https://github.com/hyperium/hyper/issues/2265#issuecomment-6...
steveklabnik 6y ago
> So Rust aborts on invalid memory accesses, unwrap on None, etc. Rust will panic on these things, and panics can abort, or unwind. Unwind is the default. That's not what's being talked about here, I don't think. This is about alloc::alloc::handle_alloc_error, which was not allowed to unwind at the time the linked comment was made. But in the last few hours, https://github.com/rust-lang/rust/pull/76448 https://github.com/rust-lang/rust/pull/76448 was linked to, which shows how that has since changed.
- brundolf 6y ago
  This is an interesting case for error-handling, because a) it can happen virtually anywhere, so handling it with Result would add huge API overhead in terms of ergonomics (given that most code never really has to think about it), yet b) it's very important that it is able to be handled in certain kinds of system contexts, which panics are not designed to facilitate. Most error cases seem to fall neatly into one camp or the other (something you always want to explicitly handle, or something where you just want to abort), but this one doesn't. handle_alloc_error seems to do well enough as a workaround, but (from my superficial reading of the GitHub thread) it feels like just a very specific "poor-man's try/catch" for this one particular case. It feels like a workaround. In general I'm a big fan of Result/panic in place of traditional exceptions, but this usecase makes it really quite unideal
  - a1369209993 6y ago
    > This is an interesting case for error-handling, [...] Part of the problem is that it's actually two different error cases: A, the data we're operating on is too large, versus B: the system as a whole doesn't have enough memory. Case A is obviously[0] a explicitly-handle error (just like "the data we're operating on is malformed"), whereas case B is obviously a just-give-up error (like "the system doesn't have a floating-point unit"). But there doesn't seem to be any practical way to reliably distinguish the two cases, and it's not clear they can be rigorously separated even in principle. 0: we might decide to 'handle' it by aborting, but that's not special to allocation

txdv 6y ago

basically there are already a lot of interchangeable backends, they are going to introduce a new one written in rust, which should increase memory security, but rust itself does not cleanup itself when it panics

dang 6y ago

I guess we'll change the URL to that from https://www.abetterinternet.org/post/memory-safe-curl/ https://www.abetterinternet.org/post/memory-safe-curl/, since the blog post has at least some technical detail. Thanks!