5 ms·

Your comment would be better without the last sentence. And the handling of that CVE does illustrate a key difference between Rust and C++. Rust says "it's our

Your comment would be better without the last sentence. And the handling of that CVE does illustrate a key difference between Rust and C++. Rust says "it's our fault if we get the intuitive semantics wrong". C++ says "it's your fault for relying on your intuition". It does no good to pretend there's no difference between the two philosophies.

ncmncm 5y ago
You seem to be saying Rust patches up the most obvious Posix holes but leaves the more subtle ones, to make it seem more secure without, in fact, being more secure.
- pcwalton 5y ago
  If you fix some issues but not others (the fact that we aren't being specific about which POSIX issues we're referring to is driving me crazy, but anyway) you have in fact improved security. The "well, if it can't be perfect, there's no point in doing anything at all" attitude is deeply pernicious, and it would be unfortunate if that is what C++ has adopted.
  - ncmncm 5y ago
    If you fix a filed complaint, but leave in place the same means to break in as before, that is what we call "security theater", which has a well-deserved poor reputation.
    - littlestymaar 5y ago
      Can you expand how this is the case here? Where does the Rust standard library leave a “subtle Posix bug” unpatched?
      - pjmlp 5y ago
        There are so many, if Rust wants to do it right across the board, then for every POSIX API where the behavior isn't fully specified, they need to provide a correct way. https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap01.html https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd... And if you want a specific example, thread cancelation cannot be wrapped in safe Rust, because many details depend on the actual UNIX is being used. https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap02.html#tag_22_02_09_21 https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh...
        littlestymaar 5y ago
        > cannot be wrapped in safe Rust There are a lot of things that cannot be exposed in safe Rust (and that's OK, that's what `unsafe` is made for). There's a big difference between “using this is unsafe, and you must use the `unsafe` keyword and be sure to manually check your invariants” and “oops you used a safe function from the standard library and it was in fact unsafe too bad”.
        pjmlp 5y ago
        The safety problem that gets lost, is that the only guarantees safe Rust can offer are related to memory corruption.
        tialaramex 5y ago
        We're literally in a thread about a guarantee that Rust kept (but C++ didn't) for filesystem APIs. So "related to memory corruption" is either a deliberately vague statement such that you can count "deleted files you didn't intend" as "memory corruption" or you're missing the true extent of what's offered here. Type safety could also be argued to just be about "memory corruption" but because of the newtype idiom Rust's type safety ensures all sorts of critical things that you wouldn't associate with "memory corruption" as it is ordinarily understood, starting with obvious built-ins like str really being UTF-8 and Saturating<i16> really having saturating arithmetic operations despite only being an ordinary 16-bit integer - but building up to Mutex<Thing> genuinely not letting you access the Thing without taking the Mutex, and GPIO types that reflect the reality that this GPIO is either a PCM device, or it is a serial port, but it by definition is only one thing at a time and must be explicitly switched between them if that's what you want to do.

ncmncm 5y ago

You seem to be saying Rust patches up the most obvious Posix holes but leaves the more subtle ones, to make it seem more secure without, in fact, being more secure.

pcwalton 5y ago
If you fix some issues but not others (the fact that we aren't being specific about which POSIX issues we're referring to is driving me crazy, but anyway) you have in fact improved security. The "well, if it can't be perfect, there's no point in doing anything at all" attitude is deeply pernicious, and it would be unfortunate if that is what C++ has adopted.
- ncmncm 5y ago
  If you fix a filed complaint, but leave in place the same means to break in as before, that is what we call "security theater", which has a well-deserved poor reputation.
  - littlestymaar 5y ago
    Can you expand how this is the case here? Where does the Rust standard library leave a “subtle Posix bug” unpatched?
    - pjmlp 5y ago
      There are so many, if Rust wants to do it right across the board, then for every POSIX API where the behavior isn't fully specified, they need to provide a correct way. https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap01.html https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd... And if you want a specific example, thread cancelation cannot be wrapped in safe Rust, because many details depend on the actual UNIX is being used. https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap02.html#tag_22_02_09_21 https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh...
      - littlestymaar 5y ago
        > cannot be wrapped in safe Rust There are a lot of things that cannot be exposed in safe Rust (and that's OK, that's what `unsafe` is made for). There's a big difference between “using this is unsafe, and you must use the `unsafe` keyword and be sure to manually check your invariants” and “oops you used a safe function from the standard library and it was in fact unsafe too bad”.
        pjmlp 5y ago
        The safety problem that gets lost, is that the only guarantees safe Rust can offer are related to memory corruption.
        tialaramex 5y ago
        We're literally in a thread about a guarantee that Rust kept (but C++ didn't) for filesystem APIs. So "related to memory corruption" is either a deliberately vague statement such that you can count "deleted files you didn't intend" as "memory corruption" or you're missing the true extent of what's offered here. Type safety could also be argued to just be about "memory corruption" but because of the newtype idiom Rust's type safety ensures all sorts of critical things that you wouldn't associate with "memory corruption" as it is ordinarily understood, starting with obvious built-ins like str really being UTF-8 and Saturating<i16> really having saturating arithmetic operations despite only being an ordinary 16-bit integer - but building up to Mutex<Thing> genuinely not letting you access the Thing without taking the Mutex, and GPIO types that reflect the reality that this GPIO is either a PCM device, or it is a serial port, but it by definition is only one thing at a time and must be explicitly switched between them if that's what you want to do.