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.
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.
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
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.
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
> 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.
"Saying the quiet part out loud: CVEs are known to be an imprecise metric. We use it because it’s the metric we have, at least for security vulnerabilities, but we should use it with care. This may surprise you, as it did me, because we hear a lot about CVEs. But whenever I’ve suggested improvements for C++ and measuring “success” via a reduction in CVEs (including in this essay), security experts insist to me that CVEs aren’t a great metric to use… including the same experts who had previously quoted the 70% CVE number to me. "
-Herb Sutter
That's from the article we're discussing and you knew that because you also acknowledged that:
> The author concedes that CVEs are not a good metric to measure by, but implies that maybe C and C++ have too many CVEs that shouldn't actually be CVEs and that the C++ community should take more control of CVEs being filed. This is ominous, and makes me fear we might start to see fewer C and C++ CVEs because issues will be closed as "intended behaviour" or "won't fix", like the filesystem issue above.
So you know that Herb isn't arguing that CVEs are ideal. You instead took a wrong baseline assumption (that C++ didn't care about the FS issue) and turned it into some weird claim that the result will just be the C++ community refusing to fix or acknowledge CVEs in order to drive the count down.
You're arguing two conflicting ideas:
Point 1: C++ is bad because there's no one ensuring CVEs & blog posts are filed for issues
Point 2: C++ is bad because a central CVE would just let them hide the issues they're desperate to hide
Despite your only evidence for either of these being something you made up entirely, as you eventually reluctantly admitted.
1. They're underreporting CVEs as of today. You acknowledge that a CVE should have been filed for the FS issue but it wasn't. I say it wasn't because the community has a cavalier attitude towards security and they didn't think it was worthy of a CVE. Nothing you've said contradicts this
2. Herb Sutter argues that there should be more control over what CVEs are filed because he's not happy with the ones being filed today, which may merely be bugs and not vulnerabilities. This may make the situation worse, with even fewer CVEs being filed. That's juking the stats.
Herb does acknowledge that CVEs aren't ideal, but the entire article is based on getting the number of CVEs in C++ down to a level comparable with Rust. He wouldn't have set that as a goal if he truly thought CVEs were meaningless.
By the way, I'm still waiting on the link for the fix in MSVC. Or did you give up on it because you saw steveklabnik's comment where he links to an MSVC maintainer saying there's no point fixing it in MSVC without changing the spec? (https://old.reddit.com/r/cpp/comments/151cnlc/a_safety_cultu...).
> something you made up entirely, as you eventually reluctantly admitted
I didn't make up anything, nor did I admit anything. My information was outdated, and I said I was wrong. You're accusing me of lying when I didn't, which make it hard to interact with you.
I say only this. Don't harp on a mistake I made and admitted to, and instead address the substance of what I said.
1. CVEs between languages aren't comparable (you don't dispute this).
2. C++ community should have filed CVEs for this issue but didn't (you don't dispute this).
3. The lack of CVEs indicates that they have a much lower standard for security.
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].
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.
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.
JS is maybe closer on this front but it's also quite old & JS is also a mess & a lot of development has shifted to TS as the language for those reasons & TS only has 1 frontend & no formal spec.
Still, if memory serves there have been a handful of cases where egc's implementation of the spec differed from javac's with resulting fixes in javac itself (though I don't have sources at hand, so perhaps I misremember).
* Rust
* Python
* Ruby
* PHP
* TypeScript
Last updated Jan 2016.
[1] https://javascript.xgqfrms.xyz/pdfs/TypeScript%20Language%20...
Here's my line in the sand: After the Mother of All Demos, if you're trying to agree things internationally and you are physically moving people to a location to do that you're doing it wrong, but maybe you don't know that yet. After JIPS ceases to be a pilot project, not knowing you're doing it wrong means you're grossly incompetent.
Those two dates are somewhat arbitrary, I picked them deliberately but I can entertain other nearby events for the same purpose. In particular if you're in Asia or Africa the JIPS date seems very arbitrary, I pick it because in my opinion this outcome (The United Kingdom's tertiary education will use IP not X.series standards) firmly means the Third Network will be the Internet not the X.25 standard. X.25 can win if only the Americans do IP, but it can't once IP spreads and that's what JIPS is.
I'm far from convinced Rust should have standardization via some SDO, but if it did need that then I'm sure ISO is the last place to go. ETSI isn't great, but it's already better than JTC1. If some corporates insist on an ISO document, mint the document somewhere else and just get ISO to put their stamp on it, have the corp. pay for that - but tell anybody who cares to ignore the stupid ISO document.
You (Steve) undoubtedly know that C++ 23 is a thing, they signed off on it mostly in 2022 and a little bit of 2023, but because ISO is awful actually ISO/IEC 14882:2023 doesn't exist, they are still working through the tedious process of agreeing to publish a document everybody settled on twelve months or more ago.
This process was fine for, I dunno, standardising how the plastic joints fit together on a water pipeline. Maybe it takes a few years to nail down exactly the text, you standardise it, nobody needs to revisit for decades at least. It's stupid for a programming language.