All I'm saying is that the CVE process is a human one, with lots of nuance. You're pointing out one aspect of that, that some CVEs are very practical, and others are more theoretical. I was trying to chime in with a similar way in which this is expressed, in that an identical bug in the standard library of one language may be a CVE, while in the other, it may not be a CVE, even with the same problem in both of them. That's "not an issue" in the sense that yeah, of course, Rust cares about this a lot more, so it's a more serious problem in Rust, so this process is legitimate, but it is in the sense that depending on how you're trying to do comparisons, there's more complexity than simply tallying up CVE counts.
CVEs aren’t really anything but an identifier for a problem. It says nothing about its severity, exploitability, or in some cases, whether it is even an actual bug. You can effectively get one for ~free. This is one of the reasons why tallying up their counts is not useful, but others include things like “people focus on some software more”.
With that said, I wouldn’t bring up this distinction here. The problem here is identical but Rust bills itself as a language where it takes responsibility for correctness bugs while C++ is a language where correctness is something that the programmer is supposed to provide. That doesn’t mean the Rust CVE is any less valid or complicated than the other CVE, it’s just that the bug would get assigned to Chromium or IOAccelerator. So if you’re saying that you shouldn’t just look at the number of CVEs and claim that Rust is somehow less secure: yes, absolutely. But if you’re saying this because you want to point out that Rust CVEs are somehow lesser because they are self-imposed, then no, that’s not true.
