4 ms·

> Can you find a link that substantiates your claim? You're throwing out some heavy accusations here that don't seem to match reality at all. Relevant piece of

> Can you find a link that substantiates your claim? You're throwing out some heavy accusations here that don't seem to match reality at all. Relevant piece of the standard: http://eel.is/c++draft/fs.race.behavior#1.sentence-2 http://eel.is/c++draft/fs.race.behavior#1.sentence-2 Officially it's undefined behavior. And here's a comment from the maintainer of the STL in MSVC regarding this: https://old.reddit.com/r/cpp/comments/151cnlc/a_safety_culture_and_c_we_need_to_talk_about/js8m9sp/ https://old.reddit.com/r/cpp/comments/151cnlc/a_safety_cultu...

kllrnohj 3y ago
That statement really doesn't support your claim and unsurprisingly Rust has the same basic caveat because of course it does, it's not possible for a language to guarantee exclusive IO access to the filesystem. https://doc.rust-lang.org/std/io/index.html#io-safety https://doc.rust-lang.org/std/io/index.html#io-safety
- vlovich123 3y ago
  The Rust docs say something substantively different about safety from what the C++ standard says. The Rust docs are talking about the safety and soundness of keeping track of the fd ownership. The C++ standard says that FS races are UB.
  - kllrnohj 3y ago
    FS races in Rust are UB as well, they're just scared to say that very explicitly. They hide behind this phrasing: "Many I/O functions throughout the standard library are documented to indicate what various library or syscalls they are delegated to. " And just think about it rationally for a second. The FS is implemented by the kernel, which doesn't give a damn what language you're using. So Rust cannot possibly guarantee anything about it. Everything about Rust's FS API is every bit as full of UB as C++'s because it's a shared system with external processes - Rust can't guarantee shit. They just make you go look up what the syscalls are to find out what the guarantees (or lack-thereof) actually are instead.
    - nindalf 3y ago
      > Rust can't guarantee shit And yet, the Rust community takes it seriously, issuing a CVE, a point release and a blog post. You won't find these 3 from all 3 major C++ implementations (clang, gcc and msvc) because they don't take the issue as seriously because their spec says they don't have to. Rust can't guarantee shit but at least they do shit when there's a problem. They take accountability for their shit. You keep harping on minor nitpicks, but you can't escape the fact that the C++ community did not take this issue as seriously as Rust did. Therefore it is meaningless to compare CVEs across the two ecosystems, which was the substance of the top level comment.
      - kllrnohj 3y ago
        > because they don't take the issue as seriously because their spec says they don't have to. And yet they all quickly fixed the issue and nobody tried to hide behind "the spec" Should there have been a CVE? Probably. But there's no central C++ CVE committee to have done that, either, which to Herb's point there probably should be. Should there have been a blog post? Probably not. People don't ship their own standard library, so the blog post is low value. What matters is whether or not distros/OS's picked up that fix promptly. Which unfortunately is hard to find out since most Linux distros suck ass at keeping their standard libraries up to date.
        nindalf 3y ago
        > they all quickly fixed the issue I notice you linked the fixes for clang and gcc. Where's the link for MSVC? > Should there have been a CVE? Probably. Glad you agree. But the absence of it proves the point I'm trying to make - they didn't take it seriously enough. > there's no central C++ CVE committee to have done that, either, which to Herb's point It actually sounds like Herb wants to reduce the the number of C++ CVEs that are filed, not increase them. He very specifically says that a bug shouldn't be enough, there should be a vulnerability. It sounds like he wants to achieve his goal of fewer CVEs by juking the stats, but who knows.
    - fch42 3y ago
      Even worse, in fact. While one can happily argue (non-)justifications for this till everyone's blue in the face, filesystem interfaces (in UNIX, but with a little magic sprinkle in Windows as well) have always allowed for concurrent access to the same file via two different handles. Open the file twice, and use the two - entirely "independent" objects for any language - filedescriptors to change the contents underneath each other. System behaviour here allows for things that "rust as a language" does not (* - I know about inner mutability but that's a different thing; even the data retrieved from a readonly-opened file can change if a second writeable open happened on it). In the end, programming languages and their standard runtimes depend on the behaviour of the operating system. I actually love that rust exposes this via system-specific traits. The "extreme" would be to go the "Oberon Way" - write the system for the language that implements the system written in that language. Maybe we'll get "somewhere there" with rust one day. Maybe not. Personally, I don't see the value in it, but mileage may vary.

kllrnohj 3y ago

That statement really doesn't support your claim and unsurprisingly Rust has the same basic caveat because of course it does, it's not possible for a language to guarantee exclusive IO access to the filesystem. https://doc.rust-lang.org/std/io/index.html#io-safety https://doc.rust-lang.org/std/io/index.html#io-safety

vlovich123 3y ago
The Rust docs say something substantively different about safety from what the C++ standard says. The Rust docs are talking about the safety and soundness of keeping track of the fd ownership. The C++ standard says that FS races are UB.
- kllrnohj 3y ago
  FS races in Rust are UB as well, they're just scared to say that very explicitly. They hide behind this phrasing: "Many I/O functions throughout the standard library are documented to indicate what various library or syscalls they are delegated to. " And just think about it rationally for a second. The FS is implemented by the kernel, which doesn't give a damn what language you're using. So Rust cannot possibly guarantee anything about it. Everything about Rust's FS API is every bit as full of UB as C++'s because it's a shared system with external processes - Rust can't guarantee shit. They just make you go look up what the syscalls are to find out what the guarantees (or lack-thereof) actually are instead.
  - nindalf 3y ago
    > Rust can't guarantee shit And yet, the Rust community takes it seriously, issuing a CVE, a point release and a blog post. You won't find these 3 from all 3 major C++ implementations (clang, gcc and msvc) because they don't take the issue as seriously because their spec says they don't have to. Rust can't guarantee shit but at least they do shit when there's a problem. They take accountability for their shit. You keep harping on minor nitpicks, but you can't escape the fact that the C++ community did not take this issue as seriously as Rust did. Therefore it is meaningless to compare CVEs across the two ecosystems, which was the substance of the top level comment.
    - kllrnohj 3y ago
      > because they don't take the issue as seriously because their spec says they don't have to. And yet they all quickly fixed the issue and nobody tried to hide behind "the spec" Should there have been a CVE? Probably. But there's no central C++ CVE committee to have done that, either, which to Herb's point there probably should be. Should there have been a blog post? Probably not. People don't ship their own standard library, so the blog post is low value. What matters is whether or not distros/OS's picked up that fix promptly. Which unfortunately is hard to find out since most Linux distros suck ass at keeping their standard libraries up to date.
      - nindalf 3y ago
        > they all quickly fixed the issue I notice you linked the fixes for clang and gcc. Where's the link for MSVC? > Should there have been a CVE? Probably. Glad you agree. But the absence of it proves the point I'm trying to make - they didn't take it seriously enough. > there's no central C++ CVE committee to have done that, either, which to Herb's point It actually sounds like Herb wants to reduce the the number of C++ CVEs that are filed, not increase them. He very specifically says that a bug shouldn't be enough, there should be a vulnerability. It sounds like he wants to achieve his goal of fewer CVEs by juking the stats, but who knows.
  - fch42 3y ago
    Even worse, in fact. While one can happily argue (non-)justifications for this till everyone's blue in the face, filesystem interfaces (in UNIX, but with a little magic sprinkle in Windows as well) have always allowed for concurrent access to the same file via two different handles. Open the file twice, and use the two - entirely "independent" objects for any language - filedescriptors to change the contents underneath each other. System behaviour here allows for things that "rust as a language" does not (* - I know about inner mutability but that's a different thing; even the data retrieved from a readonly-opened file can change if a second writeable open happened on it). In the end, programming languages and their standard runtimes depend on the behaviour of the operating system. I actually love that rust exposes this via system-specific traits. The "extreme" would be to go the "Oberon Way" - write the system for the language that implements the system written in that language. Maybe we'll get "somewhere there" with rust one day. Maybe not. Personally, I don't see the value in it, but mileage may vary.