5 ms·

Most sensible developers develop software against compiler specifications, not the standard. Very very little useful software can be implemented strictly within

Most sensible developers develop software against compiler specifications, not the standard. Very very little useful software can be implemented strictly within what's offered by the standard.

temac 3y ago
That's very not a reason to justify the critical shortcomings of a standard, especially so when implementations are known to make their practical safeties regress in the name of they are allowed by the letter. In that context the very culture of C++ normalizers and implementers has to change and the introduction of this paper is a step in the wrong direction in that regard.
- gpderetta 3y ago
  Realistically the only improvement to the spec is changing fs races from undefined behaviour to something less program-invalidating. But to what? Unspecified behaviour would require the standard to give a set of possible outcomes which might not be implementable. Implementation defined would still require the compiler to pick and document a specific behaviour which might also not be possible to guarantee. The only way to provide stronger guarantees is to rigorously define the behaviour of the OS, which is of course not possible. Not even POSIX does that and of course C++ targets beyond POSIX. The reality is that there are a lot of things that are commonly done that are formally undefined (for example mmap, ldopen, openmp) and the user has to look for details beyond the C++ standard and into other documents (other standards, the compiler manual). The alternative is a fully defined isolated sandbox, but that would be pointless for a system language and not even Java attempts that.
  - kllrnohj 3y ago
    Or put another way, find a language, any language, that defines all possible scenarios of a file system race condition in a multi threading & multi process system. It's not possible to do such a thing, and of course nobody does. They just avoid using the term "undefined behavior" even though it absolutely is. Which makes this whole thread absolutely absurd. It's the worst possible example of Rust vs. C++ CVE as the language doesn't get an opinion here at all in the first place
    - nindalf 3y ago
      No, it's an excellent example. Rust issued a CVE, an immediate point release with a fix for the issue and a blog post explaining the problem and what they did. 2 C++ implementations fixed the issue, but no CVE or blog post. No point release either AFAIK. You harp on the fact that this is undefined in all languages. Yeah sure. But some languages take the report seriously and communicate that to their users. They don't hide behind "spec says UB" or "it's the file system's fault". They take accountability and fix it. Other languages don't because that's the prevailing culture there. That's what you're missing when you're trying to make it seem like there's no difference between Rust and C++. There's a vast difference in how each community takes security. That's why its meaningless to compare the number of CVEs in both languages. Even if C++ reduced the number of CVEs by 90% it still would not be as secure as Rust because 1 C++ CVE is not the same as 1 Rust CVE.
      - kllrnohj 3y ago
        You're moving the goalposts so fast you could be competing with C++ for prioritizing performance over soundness. Reminder that your original claim was: > The problem definitely exists in C++, but it's not acknowledged as a problem, let alone fixed. Now it's degraded to just "but there wasn't a CVE or blog post!" which isn't even that relevant to the broader argument of Herb's that all the language guarantees don't prevent logic bugs (hence how Rust was able to have this CVE in the first place). There's a point of "good enough" for the language itself. Nobody is making any argument that CVE count is the best or optimal metric for anything
        nindalf 3y ago
        I didn't move the goalposts. I was going off my recollection at the time, which was a discussion around the Rust blog post and CVE. Here's a comment from me a day ago saying "I stand corrected" (https://news.ycombinator.com/item?id=39680754 https://news.ycombinator.com/item?id=39680754). > Nobody is making any argument that CVE count is the best or optimal metric for anything Except, you know, Herb Sutter in the article we're supposedly discussing. He's arguing that it's possible to compare Rust and C++ CVEs and that C++ would be just as good as Rust if the CVE counts were similar. If you took the trouble of addressing the substance of my comment that Rust and C++ CVEs aren't comparable, rather than exulting in being technically correct because you found a mistake, you would have realised that. You're welcome to assume bad faith of me, but that was the substance of my comment. I'm sorry I didn't keep in touch with every commit made to C++ compiler repos and I spoke out of turn. But I never moved the goalposts - those were always fixed on the issue that comparing CVEs between a language that takes security seriously and one that doesn't is a dumb idea.
  - aw1621107 3y ago
    > Unspecified behaviour would require the standard to give a set of possible outcomes I don't think there is a requirement that the possible unspecified behaviors are enumerated. The current C++ draft [0] states possible behaviors are "usually" enumerated, but "usually" is not "always", and there's no explicit direction that those behaviors are the only allowable options. There's also the definition from the C89 spec which doesn't even have that language, only stating that the standard imposes no requirements on the unspecified behavior [1]. [0]: https://eel.is/c++draft/intro.defs#defns.unspecified https://eel.is/c++draft/intro.defs#defns.unspecified [1]: http://port70.net/%7Ensz/c/c89/c89-draft.html#1.6 http://port70.net/%7Ensz/c/c89/c89-draft.html#1.6
thfuran 3y ago
That sounds like the hallmark of a defective language to me.
- gpderetta 3y ago
  most languages don't even have a specification.
  - pizlonator 3y ago
    Yes! This is much under appreciated. Usually, it’s just some core calculus of the language that is rigorously specified and the rest is hand waving. There are some exceptions like JS. But even Java has the problem that if you just implement what’s in the spec, you won’t be able to run anything meaningful unless you also do things exactly how the JDK would. You can find out what the JDK does by reading its code and writing test cases and I think that’s what folks do, if they want to be compatible. UB and memory safety are orthogonal. If we specified formally and super rigorously that a pointer is an integer and that memory is an array of bytes, we could have a UB-free language but memory safety would still be on fire.
    - gpderetta 3y ago
      Everything is memory safe if your only datatype is uint8_t /s
      - pizlonator 3y ago
        Yup :-)
    - tialaramex 3y ago
      > If we specified formally and super rigorously that a pointer is an integer and that memory is an array of bytes, we could have a UB-free language That's PVI (Provenance Via Integers) and it's a performance disaster. If anything in memory might be pointed to, almost all the nice modern optimisations aren't correct. It is really popular with a certain kind of "Portable assembler" programmer, who typically has no idea how the machine actually works, nor how their language is defined but is very confident the nonsense they're writing ought to do what they wanted it to do. So, the "bad" news is that you can't have this, your compiler vendor won't make it, and the "good" news is that you'd have hated it anyway which is why they won't make it.

Most sensible developers develop software against compiler specifications, not the standard. Very very little useful software can be implemented strictly within what's offered by the standard.

temac 3y ago

That's very not a reason to justify the critical shortcomings of a standard, especially so when implementations are known to make their practical safeties regress in the name of they are allowed by the letter. In that context the very culture of C++ normalizers and implementers has to change and the introduction of this paper is a step in the wrong direction in that regard.

gpderetta 3y ago
Realistically the only improvement to the spec is changing fs races from undefined behaviour to something less program-invalidating. But to what? Unspecified behaviour would require the standard to give a set of possible outcomes which might not be implementable. Implementation defined would still require the compiler to pick and document a specific behaviour which might also not be possible to guarantee. The only way to provide stronger guarantees is to rigorously define the behaviour of the OS, which is of course not possible. Not even POSIX does that and of course C++ targets beyond POSIX. The reality is that there are a lot of things that are commonly done that are formally undefined (for example mmap, ldopen, openmp) and the user has to look for details beyond the C++ standard and into other documents (other standards, the compiler manual). The alternative is a fully defined isolated sandbox, but that would be pointless for a system language and not even Java attempts that.
- kllrnohj 3y ago
  Or put another way, find a language, any language, that defines all possible scenarios of a file system race condition in a multi threading & multi process system. It's not possible to do such a thing, and of course nobody does. They just avoid using the term "undefined behavior" even though it absolutely is. Which makes this whole thread absolutely absurd. It's the worst possible example of Rust vs. C++ CVE as the language doesn't get an opinion here at all in the first place
  - nindalf 3y ago
    No, it's an excellent example. Rust issued a CVE, an immediate point release with a fix for the issue and a blog post explaining the problem and what they did. 2 C++ implementations fixed the issue, but no CVE or blog post. No point release either AFAIK. You harp on the fact that this is undefined in all languages. Yeah sure. But some languages take the report seriously and communicate that to their users. They don't hide behind "spec says UB" or "it's the file system's fault". They take accountability and fix it. Other languages don't because that's the prevailing culture there. That's what you're missing when you're trying to make it seem like there's no difference between Rust and C++. There's a vast difference in how each community takes security. That's why its meaningless to compare the number of CVEs in both languages. Even if C++ reduced the number of CVEs by 90% it still would not be as secure as Rust because 1 C++ CVE is not the same as 1 Rust CVE.
    - kllrnohj 3y ago
      You're moving the goalposts so fast you could be competing with C++ for prioritizing performance over soundness. Reminder that your original claim was: > The problem definitely exists in C++, but it's not acknowledged as a problem, let alone fixed. Now it's degraded to just "but there wasn't a CVE or blog post!" which isn't even that relevant to the broader argument of Herb's that all the language guarantees don't prevent logic bugs (hence how Rust was able to have this CVE in the first place). There's a point of "good enough" for the language itself. Nobody is making any argument that CVE count is the best or optimal metric for anything
      - nindalf 3y ago
        I didn't move the goalposts. I was going off my recollection at the time, which was a discussion around the Rust blog post and CVE. Here's a comment from me a day ago saying "I stand corrected" (https://news.ycombinator.com/item?id=39680754 https://news.ycombinator.com/item?id=39680754). > Nobody is making any argument that CVE count is the best or optimal metric for anything Except, you know, Herb Sutter in the article we're supposedly discussing. He's arguing that it's possible to compare Rust and C++ CVEs and that C++ would be just as good as Rust if the CVE counts were similar. If you took the trouble of addressing the substance of my comment that Rust and C++ CVEs aren't comparable, rather than exulting in being technically correct because you found a mistake, you would have realised that. You're welcome to assume bad faith of me, but that was the substance of my comment. I'm sorry I didn't keep in touch with every commit made to C++ compiler repos and I spoke out of turn. But I never moved the goalposts - those were always fixed on the issue that comparing CVEs between a language that takes security seriously and one that doesn't is a dumb idea.
- aw1621107 3y ago
  > Unspecified behaviour would require the standard to give a set of possible outcomes I don't think there is a requirement that the possible unspecified behaviors are enumerated. The current C++ draft [0] states possible behaviors are "usually" enumerated, but "usually" is not "always", and there's no explicit direction that those behaviors are the only allowable options. There's also the definition from the C89 spec which doesn't even have that language, only stating that the standard imposes no requirements on the unspecified behavior [1]. [0]: https://eel.is/c++draft/intro.defs#defns.unspecified https://eel.is/c++draft/intro.defs#defns.unspecified [1]: http://port70.net/%7Ensz/c/c89/c89-draft.html#1.6 http://port70.net/%7Ensz/c/c89/c89-draft.html#1.6

thfuran 3y ago

That sounds like the hallmark of a defective language to me.

gpderetta 3y ago
most languages don't even have a specification.
- pizlonator 3y ago
  Yes! This is much under appreciated. Usually, it’s just some core calculus of the language that is rigorously specified and the rest is hand waving. There are some exceptions like JS. But even Java has the problem that if you just implement what’s in the spec, you won’t be able to run anything meaningful unless you also do things exactly how the JDK would. You can find out what the JDK does by reading its code and writing test cases and I think that’s what folks do, if they want to be compatible. UB and memory safety are orthogonal. If we specified formally and super rigorously that a pointer is an integer and that memory is an array of bytes, we could have a UB-free language but memory safety would still be on fire.
  - gpderetta 3y ago
    Everything is memory safe if your only datatype is uint8_t /s
    - pizlonator 3y ago
      Yup :-)
  - tialaramex 3y ago
    > If we specified formally and super rigorously that a pointer is an integer and that memory is an array of bytes, we could have a UB-free language That's PVI (Provenance Via Integers) and it's a performance disaster. If anything in memory might be pointed to, almost all the nice modern optimisations aren't correct. It is really popular with a certain kind of "Portable assembler" programmer, who typically has no idea how the machine actually works, nor how their language is defined but is very confident the nonsense they're writing ought to do what they wanted it to do. So, the "bad" news is that you can't have this, your compiler vendor won't make it, and the "good" news is that you'd have hated it anyway which is why they won't make it.