>Because sometimes I see people online who compare the number of CVEs in Rust and C/C++ software, [...]
a rule of thumb i follow is that the second someone starts comparing or talking about the number of CVEs, i just ignore whatever they say next. its hard to think of a more useless metric than "number of CVEs", especially now.
(edit: the people disagreeing are encouraged to share how you use "number of CVEs" to inform your decision making)
This is true, but security teams often work on tooling dedicated to reduce the n. of CVEs so that a company can keep compliance. That is in fact part of compliance itself to have an automated/reliable processo to tackle CVEs...
Not as a metric, but it basically becomes one, like with Fedramp.
You need to fix also moderate/low CVEs within a certain time frame.
So CVE count becomes relevant, because the target is zero, although it doesn't mandate "zero CVEs" but that's finally what the desired outcome is.
It's basically unrealistic to ignore that number, because it's unlikely that you have a steady 1000 CVEs (that are being continuously fixed and new ones discovered), but more like "a few exceptions".
But that's not a wrong approach. First you want to as many vulnerabilities as you can, than you want to fix as many as you can. If you rate the developing department for that, that's another story.
In my experience it is becoming basically ridiculous that we disallow compliance based on a number of cve, their level, etc. It's just a checkbox, but it has nothing to do with security.
I'd like to know how a "critical CVE running in your software for 29 days" is acceptable from a security standpoint. With nowadays tooling, these AI agents can take you down in no time if they target you.
Compliance the way is done today is basically outdated, but everyone has to follow these rules to sell software basically.
So lets take some recent examples from the sprawling systems my team looks after
1. There's a "critical" severity security issue because we have an obsolete version of some Perl library on a machine that's exposed to outsiders (ie has a public HTTPS website)
1a. The perl library isn't used by any of the software running on that machine, it's presumably either left over from software we no longer use or it was installed to run somebody's one-shot Perl script, possibly years ago, maybe even for a prior incarnation of that system, with the present one installing that library because it's just easier than figuring out which libraries are still needed...
1b Severity CRITICAL. Actual threat: ZERO
2. .NET 8 is obsolete, machines with the .NET 8 CLR are flagged as insecure.
2a. .NET 10 isn't obsolete, that's still supported, in many cases the exact same code, re-compiled with a 10.x version not 8.x was shipped by Microsoft. Is that true for all the cases we care about? Nobody knows, nobody is even interested in working out. Flagged instances will be turned off if they're not fixed so "just" fix it. Busy work.
2b. Severity HIGH. Actual threat: Unknown, possibly negligible?
As with Mythos these "AI agents" which can "take you down in no time" can't do the impossible, this isn't a Hollywood movie, mumbling about AI and critical severity CVE doesn't turn that Perl library nobody was using into an actual threat.
Yep, at work my team's vulnerability dashboard constantly shows hundreds of critical and high vulnerabilities. Fortunately/unfortunately, 99% of these issues are for Javascript dependencies in websites that are not server-side rendered... so we look bad, even though we have no exposure to most of these vulnerabilities.
Just yesterday I made myself a NuGet package analyzer tool -- okay fine, I vibe coded it -- that has convenient buttons for filtering out client-side packages, test projects, and dev-time tooling like Aspire.NET.
"The HTML parser is now written in Rust"
"The Rust parser is also about 10% faster than the C++ version it replaced,"
I am not saying this is a systematic analysis by far, but Rust is pushing into domains where C and C++ dominated in the past. And that seems to be a real push. To me it looks as if both C and C++ are standing to lose some ground in the next few years, directly to Rust. Perhaps even via snowball effect.
A not inconsiderable part of why is that Rust for Linux did the work.
When C++ people say they think there should be C++ in Linux, their proposal usually begins by proposing that it "should" be possible to just compile Linux as C++ software. This doesn't work because C isn't just "C++ but old", and they rapidly lose interest.
Which of course also feeds into Linus' semi-fair claim that not allowing C++ keeps out the low effort wannabes who would plague such a project. This makes C++ developers very angry, but part of the reason why is that it's true, C++ does attract these people.
The Rust for Linux people wrote a lot of code, a lot of documentation, they did Q&As, they worked very hard to actually deliver the idea to the kernel community, it's a totally different approach, it's a lot more work but some people thought it was worth the work.
> their proposal usually begins by proposing that it "should" be possible to just compile Linux as C++ software
That has already been done in the past. Quoting the FAQ:
"[...] the kernel was once modified to be compiled under g++. That lasted for a few revisions. People complained about the performance drop. It turned out that compiling a piece of C code with g++ would give you worse code. It shouldn't have made a difference, but it did. Been there, done that."
Honestly this just makes it sound like C++ people either didn't really care about it in practice or just were weirdly insistent that they get to decide how to integrate the language into an existing project. At best, it's just another instance of the claims that C++ could totally do everything Rust does (but somehow still never seems to in real life), and at worst it just kind of reflects poorly on the social skills of the people who tried to push it.
Sure, not caring about contributing to Linux in practice is valid, but at that point it would make more sense just not to argue about the aptness of C++ for integrating into Linux at all then if no one ever legitimately tried. My point is that the parent comment is trying to have it both ways by arguing that C++ totally could be integrated into the Linux kernel as a dismissal of the real-world case of Rust being integrated but then ignoring the actual real-world case of C++ not getting integrated into the kernel.
At a higher level, I've noticed a long-term trend where dismissals of Rust from C++ proponents have continued to grow increasingly abstract; the line of reasoning basically seems to be that how Rust is used in practice can be ignored as long as there's a sufficient theoretical argument for C++ being able to do the same thing. This is a remarkable retreat from the previous objections to Rust being impractical compared to C++ which I'd argue is itself evidence of the ground that Rust has gained in the past several years. It seems to have happened without the C++ community noticing though, which at least in part seems to come from some cognitive dissonance; in your two replies to my comments in this thread, you demonstrated this yourself by arguing on pragmatic grounds about how C++ is used in practice in this comment but then rejecting criticism of C++ in your other comment by asserting that a "recipe" for memory safety is enough to dismiss concerns about how pretty much no real-world project actually achieves this.
My (obviously biased) perception is that the shortcomings of Rust tend to be pretty widely agreed upon by the experts in the community and mostly dismissed by people who honestly aren't nearly as experienced in the language, whereas with C++ the most expert members of the community seem prone to handwaving away concerns that deserve a lot more attention.
I agree about Rust gaining ground but using the argument that it got 10% faster due to Rust is not really that useful.
If they rewrote it in C++ again, they would have most likely got the same result because they got a chance to fix a design that might not have been most optimal.
I don't think it's due to Rust being inherently faster, but there have been plenty of documented cases of being able to take better advantage of concurrency due to the guarantee of no data races. Trying to do the same in C++ would expose new risks to UB, at which point you're just kind of back to the same safety argument that presumably motivated the move to Rust in the first place
I think the difference in languages that allows for faster performance is that Rust does a good job of surfacing expensive operations and it makes defensive programming less of a requirement.
> If they rewrote it in C++ again, they would have most likely got the same result because they got a chance to fix a design that might not have been most optimal.
This speculation has been offered every time. It's not crazy to think this might be true, but it's also not crazy to think that if C++ keeps leaving performance on the table and Rust doesn't that adds up for real projects.
When Titus wrote "ABI: Now or Never" in 2020 he estimated 5-10% aggregate loss. Things that you could fix, if you started over, but C++ refuses to do that because of ABI and so it doesn't have these fixes, whereas in most cases† Rust does. So I can well believe that a blow-for-blow port could get you 10% perf win.
† One of the examples Titus cites is the "Small String Optimization". Rust deliberately doesn't do SSO for its standard library collection String, but several really nice SSO optimised types are available, including ColdString and CompactString, which are way better than what's provided in C++ if that's what you need.
Until Rust has equal meta-programming support to C++ it's always going to be "slower". That's why people always say this because it's always true there is nothing Rust can do C++ can't but there is quite a few things you can do in C++ but not in Rust.
Realistically the difference doesn't matter much and if you're writing code that must be as fast as possible your writing unsafe Rust that looks a lot more like C/C++ then anything Rust.
> Until Rust has equal meta-programming support to C++ it's always going to be "slower".
What metaprogramming does C++ have that rust is lacking?
If you need more than traits + generics, rust also has proc macros. Proc macros are essentially portable compiler extensions. They take in a stream of symbols from the user's program at compile time and emit rust code that gets passed straight to the compiler. You lose out on syntax highlighting and they make compilation slower. But macros are essentially compile-time code gen. They work great. In rust, you can do things like JSX at compile-time without any special compiler support. (See: leptos.)
> Realistically the difference doesn't matter much and if you're writing code that must be as fast as possible your writing unsafe Rust that looks a lot more like C/C++ then anything Rust.
I agree that the difference is small in practice. Good rust often does look a lot like C - with plain structs everywhere and lots of global-ish scoped functions.
But I don't agree about unsafe. I've spent some time porting well optimised code from C to rust. I generally find I need far less unsafe code than I expected. I ported a ~500 line skip list implementation from C to rust a few years ago. I think my rust code ended up using just 2 unsafe functions. The rest of the code didn't need any unsafe at all.
My skip list was a monster to debug in C because most logic bugs ended up corrupting memory. As a result, a bug in one function caused crashes in far away code. In rust, debugging was much easier. There wasn't any "spooky action at a distance". And that let me reason about the code much more easily. As a result, once I got it working I ended up adding a few more optimisations in rust that I was too overwhelmed to write in C. The rust code is now ~2-3x faster.
> there is nothing Rust can do C++ can't but there is quite a few things you can do in C++ but not in Rust
The point the parent comment is making is that this doesn't really matter if no one actually does do these things in C++. It's absolutely wild to me how quickly the arguments in favor of C++ instead of Rust have reversed in about a decade; people used to argue that the benefits of Rust were all theoretical and in practice people who were used to C++ could write it perfectly fine without safety issues, and now it's somehow that the theory that gives C++ the advantage and we don't need to care about whether those supposed advantages ever actually exist in practice.
> Until Rust has equal meta-programming support to C++ it's always going to be "slower".
I don't think that makes a lot of sense even theoretically because of e.g. aliasing, but it doesn't matter because as I said, C++ chooses to be slower, Titus gives a number of examples where we know how to do X fast, and that's how Rust does X - in theory C++ could X the same way, but none of the three C++ compilers people actually use do it, because they picked wrong and then froze their ABI and won't thaw it.
No one writing anything that needs performance cares about some standard library ABI issues. Rust already has warts from bad API designs that constrains performance and they are unlikely to ever be fixed even with new editions. Rust will continue to pick up baggage as basically every language has done.
Aliasing has yet to provide any real benefit for Rust and a hell of a lot of issues. Maybe one day it will be a big win but realistically anyplace that aliasing matter c/c++ will just drop __restrict on it.
Sure, to simplify lets assume a 64-bit CPU (this all works for 32-bit but that's less common these days and the actual numbers are different)
C++ std::string can contain up to 15 (other popular implementations) or 22 bytes (libc++ from Clang) of inline text, and the data structure itself is either 24 bytes (Clang again) or 32 bytes of storage. Here's Raymond Chen: https://devblogs.microsoft.com/oldnewthing/20240510-00/?p=10...
CompactString is 24 bytes of storage with all 24 bytes as potential inline text. When the 24 bytes are valid UTF-8 text, then that's the content of the CompactString e.g. "https://example.org/cool", if they aren't the last byte will be invalid UTF-8, and this signals whether some of the other 23 bytes were inline UTF-8 (and if so how many) or whether they should be interpreted as a pointer, size and capacity.
ColdString is a radically different idea, it's 8 bytes of unaligned storage and it's one of three things: 1. 8 bytes of UTF-8 text, as before we can tell by whether it's valid UTF-8 text or 2. 0-7 bytes of UTF-8 text, prefixed by an invalid UTF-8 byte telling us how many of the remaining bytes are text or 3. An encoded pointer to a length-prefixed data structure, signalled by the presence of the UTF-8 continuation marker bits which should never be present in the first byte of a string.
I really like ColdString because it's so much in the "use the whole buffalo" spirit of these modern safe yet high performance types. UTF-8 has what are called "overlong prefixes" because it was invented before Unicode decided it would never grow beyond U+10_FFFF and these are often just a useless impediment, but ColdString uses those prefixes.
How do CompactString/ColdString compare to std::string implementations performance-wise? From the looks of it, they must be somewhat slower than C++ strings
On publicity side / propaganda / some specific areas you might have a point. Practically amount of C++ code being in active development (I wat to stress this particular point) dwarfs that of Rust despite all that high profile pressure.
Personally I consider languages as just a tool and do not get hung up when client prefers this or that and I have developed all kinds of software in many languages.
If asked for my own opinion - for general development I consider Rust very restrictive and poor expression-wise comparatively to C++, I think it is a case when developer become servant of a tool.
> C and C++ are kind of losing out to Rust right now.
Depends on the domain, there are enough fields where Rust still doesn't have an answer for.
Example, the compilers it depends on (botstraping on Cranelift when?), Khronos and POSIX industry standards, HFT, HPC, console devkits, AI frameworks, VFX reference platform,....
There can be made very good arguments why C is less safe than Rust, but null pointer dereferences which are perfectly safe everywhere except on weird platforms (and usually could be made safe even there by turning on a compiler flag) seems a very misleading argument.
And as as the Cloudflare incident showed, a Rust unwrap can have equally bad consequences. (or as Ariane 5 showed, a safe overflow in Ada can have explosive consequences)
A dereference in the final binary is not different from Rust. A dereference in the source code, that makes the whole program invalid, so the compiler doesn't emit a credentials check you wanted it to emit, is.
For availability and stability concerns, the C approach is actually better, but for security and reproducibility, it is not.
The check is removed only if you already dereference the pointer before doing the check. But then, you also get the trap before the check. So the compiler eliding the check is not making this worse - as long as the zero page is not mapped.
In any case, you can also configure GCC to not do this, and you can also configure it to insert explicit null checks before dereferencing a pointer. So C can offer you security and reproducibility (in this aspect).
No, it's also removed if you dereference it later on, that's why it is said, that UB has time traveling behaviour. This means, that the compiler can emit a program, that let's you access data without a security check, while the crash only comes later. Also the crash can be removed, because dereferencing it is UB anyway, so the compiler does not need to emit it.
It's not an ideal thing for sure, but between loud bang and silent corruption, I'd probably take loud bang. I.e. I'll take a panic rather than the method return 43 when you pop the null member from the stack.
And the Rust wasn't the root cause but corrupt configs were being erroneusly duplicated.
I guess this depends on what you might corrupt (if it is not valuable but irrelevant intermediate state it might be ok) and what the consequences of an outage are.
In any case, I largely tend to agree with you that this is better in most scenarios (not for the cloudflare incident though). But a segfault in C for a null pointer dereference would have exactly the same result, which is why null pointer dereferences are a terribly example if you want to show the advantages of Rust.
The only example I know where I think Rust clearly has a real advantage are lifetimes.
These Rust discussions typically contain grains of truth wrapped into exaggerations while downplaying or ignoring the two big issues of Rust, which are complexity and out of control dependency trees.
For the first issue of complexity, the reply is along the lines of show me the code and then either nitpicking that to pieces or explaining in several paragraphs how the behavior is perfectly reasonable and in fact quite easy to understand. Beginners get intimidated, professionals don’t have time to write novels on HN.
Complexity in Rust is systemic. It’s little things accumulating and amplifying each-other that add up to having to spend significant time just designing types to satisfy the static analyzer. Many Rust programmers seem to see the type system as a hammer to be used liberally, an predilection also known in the C++ metaprogramming community.
On the second topic (also present in this thread) the counter-argument is that other languages do it too and nothing bad happened so far. The former is not valid, because Rust is uniquely bad in its competitor group and security by waiting is not a valued approach.
I would argue that what you call complexity here is better referred to as explicit or visible complexity, as compared to hidden or implicit commplexity. The complexity as such comes with the domain and its application; but with Rust you can see it and you are forced to deal. With C++ you can get away with pretending that it is in fact not there.
This is honestly not intended to pick on C++ as a Rust fanboy, however. It really isn't.
For instance, to be a little unpolished, I would shrug off the unwrap incident as doing it the C++ way and pretending that the complexity does not need to be solved right then and there because ItShouldNotHappen or IKnowWhatIAmDoing.
I prefer Rust over C++, but I do not hate C++. This isn't even about C++ anyway.
When it comes to out of control dependency trees, I agree with you. But there is a trade off here too and that is that either you implement the thing or you externalize it. I use both approaches myself and am in no way excusing anything or attempting to be Rust's defense lawyer. There definitely seems to be a leftpad-problem brewing in the Rust community.
There are certainly good parts in Rust that force you deal with inherent issues explicitly. I do not think this justifies a language with the complexity of Rust, but I would agree it is preferable to C++ in this regard.
I reject the whole Rust has a high complexity premise, but I would gladly continue our conversation around it here but I would need a little more definition for that to be possible.
What do you mean by complexity in this context and in what way does Rust carry a lot of it?
I did not know this was disputed, as even developer surveys in the Rust community highlighted complexity as a concern. But seems it is the overall summary of features that make it complex: lifetime, borrowing, a polymorphic type system, traits, multiple tools to manage lifetimes, macros, proc macros, async, unsafe, panic, unwrap, etc. But I agree it is much cleaner than C++.
Is it only me that would have expected curl_getenv() to have an assert that it's argument isn't NULL?
I know this doesn't stop runtime problems in release builds, but i'd have thought this sort of simple precondition check would help users find problems in their library useage.
It's not going to stop you passing a non-terminated string, or other such invalid input though, which is I guess more the point, that it's totally possible in C to produce good looking but actually invalid arguments that can't be spotted at runtime without UB (out of bounds access etc).
Edit: Actually thinking about this more, I guess the problem is that you are likely linking against a release library implementation, so it's not possible to add a precondition without introducing a runtime overhead, which is probably more likely what we are talking about with this case.
If I were doing a code review, I would probably accept the code either with or without the assertion. The context of curl_getenv() makes it clear that null is not acceptable. If the author of curl_getenv() had evidence that callers are frequently breaking the contract by passing null, then perhaps the assertion would help shed some light on violators. Otherwise, I would expect everyone to play by the rules, making the assertion unnecessary.
The problem with asserts is that they are pretty dramatic and you crash the entire program.
We generally did this in the avahi libraries, be fairly liberal with asserts that "shouldn't happen", it is a source of complaints though because basically you can be using a third party library that uses avahi and have your program crash due to a bug in that library, or in avahi. It's extra fun when using some historical libc systems such as "NSS" and you load a plugin to do hostname resolution, which nss-mdns does.. now you can have any program on the entire system crash if you are assert happy.
On the one hand I agree that if the result is going to be memory un-safety then perhaps you should assert, but more ideally you'd just fail gracefully and throw or return an error. That can sometimes be tricky though, if there is no good way to return an error or return a NULL value or similar. Depending on the API.
But in the case of curl_getenv, returning NULL seems a valid possibility (https://curl.se/libcurl/c/curl_getenv.html) as that is indicated to be done if you don't find the requested environment variable. Arguably the NULL environment variable is not found. so, this feels likely to be acceptable. Though I could see an argument for you now assuming the environment variable you were actually looking for not existing, but you didn't actually ask for one, and now your logic is broken and maybe you introduce a different class of security bug because you change your behaviour based on some environment variable not existing.
Returning to the context of this post, this is one of the things I really like about rust. (And zig, haskell, typescript, swift and others). These languages make invalid states impossible to represent. If my function takes a value of type T (or &T), you can't accidentally receive NULL. So you just don't need to worry about this stuff any more. The compiler simply won't compile the program if type checking fails. At runtime, I only have to consider valid values.
Crashing a program is always a much better alternative than behaviours that silently lead to memory corrupt, having much severe outcomes than a crash.
Ah but what high integrity computing, well there neither crashes nor memory corruption are welcomed, hence programming guidelines and certification workflows that would make most C devs cry with the language features they are allowed to use, and how each line of code gets analysed by tools and humans.
Yes, but null pointers are so pervasive in C code that we really can't afford to put assertions everywhere. It's often better to let the app crash on violations.
A bug is a bug even when it doesn't clearly manifest itself 100% of the time, and furthermore it is pretty much guaranteed that NULL dereference crashes with segfault in practice, only not for the people playing theoretic games whose essence of life is finding gotchas where it maybe isn't so and then feeling smarter than everyone else.
But it's >> 99.9% true that this will just crash even though it's acshually UB, nasal demons and so forth. Now raise this << 0.1% likelihood that it isn't true on some system with some compiler and build flags, to the power of the number of distinct deployed configurations out there, and you get the result which is the correct engineering decision of just moving on instead of spending your life filling straightforward code with pointless boilerplate assertions.
NB it can make sense to assert nonnull when the condition won't be tested on all code paths or the intention is otherwise not super obvious.
An assert is not guaranteed to terminate the process. In C, the most common implementation choice is to completely omit the check if you're not building in debug mode.
> it's not possible to add a precondition without introducing a runtime overhead
Indeed. Adding an assertion to a single function isn't a big deal, but if every function has to check all of it's arguments, that's going to add up. And even if you could have the assertion only in debug builds, that isn't enough unless you have a very exhaustive test suite, because an edge case could trigger undefined behavior in production in a way that wasn't exercised during testing.
In fact, the fact that the rust compiler adds runtime checks for array indexes if it can't prove the index is in bounds is a criticism some c programmers have of rust.
> In fact, the fact that the rust compiler adds runtime checks for array indexes if it can't prove the index is in bounds is a criticism some c programmers have of rust.
And the fact that after a half a century we're still debating how much we really need to care about U stuff like this when we get severe bugs in a major piece of software written in C seemingly every week is a criticism that pretty much all Rust programmers have of C.
Considering the amount of C programs that exist, the "we see severe bugs in C code seemingly every week" is on the same level of propaganda as we see "crime in the news every week" when the real societal problems are entirely different.
It is so bad as C culture, that the only way to fix the culture is by having hardware where those C programmers no longer have a say on bounds checking.
Most systems languages, with exception of C, have ways to do bounds checking, even C++ and Objective-C, by using the respective collection classes.
I'm not sure i think those situations are comparable. If a rust func is taking an Option<t>, its essentially advertising that it can handle None values. That feels quite a bit different from giving a c function a null pointer and having it freak out.
Ye, sure, but Rust won’t compile a `foo(std::ptr::null())`, if the function is defined as `fn foo(b: &Baz)`. C doesn’t get that luxury. That is the point of the article.
`int x[static 1]` isn’t exactly intuitive when one wants to define a reference to an integer. Nor is this practical given a dynamic array of integers. Or a single integer field in a struct.
Can you do that with a dynamic array? If not, it's pretty severely limited (unless you mean that literally forbidding dynamic memory is usually not done, which I guess it's true outside of some embedded code but not a particularly meaningful statement).
The syntax is rather confusing. This is not an array of length 1, but rather a pointer which points to a memory segment which is at least 1 integer long. In other words, any array of any length (>=1) would be a valid argument to this function. "static" here means "don't do the normal thing where you totally ignore the length of an array argument to a function (which is, like usual, really just a pointer)". "static" was chosen because the keyword was available rather than because it was a particularly descriptive name.
I see. Can you use `static 0` for a non-null empty array, or does that run into issues around what it means to allocate 0 bytes? I feel like the distinction between "empty but safe to use" and "not safe to use, so you need to check first" is a pretty important part of what most of the solution look like in languages that don't have this problem. Being able to statically know that something is non-empty is nice, but it's not quite the same as being forced to check if it's valid.
I can understand that this a somewhat practical solution to the problem of codebase is all C and all I have is a C compiler, so there is merit to using the static keyword here. But it is also unwieldy and used rarely, so I do not think it is comparable to Rust’s borrow rules in any meaningful sense.
The syntax for using passed VM arrays is stilted; you're operating on a pointer to an array, which can get confusing and is error prone. Because of the semantics for array passing and need for backward compatibility it's too easy to get it wrong without the compiler catching mistakes and complaining. Though, the C2y _Countof operator is required to error when used on a non-array, so using _Countof(a) instead of _Countof(*a) will fail. (GCC and clang also have warning diagnostics that work for the fallback countof macro.) And there's no way (or no easy way?) to ask compilers to inject automatic bounds checking when operating on arrays, at least outside non-production debugging modes like ASan.
It's absolutely different: “I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.”
His mistake was making _all_ reference taking functions also accept null. In Rust functions opt into None | Some
This comes up with C# which must have default(T) so references default to null. In Rust there is no general default(T) that must always resolve
My contrast was to "That feels quite a bit different". The type system in C only has Tony's nullable references, you can't say that you don't mean that because it wasn't your choice to make, it's like if some C programmers say obviously they don't mean zero when they take an integer - too bad, C doesn't have the non-zero integers (Rust does, NonZeroI32 for example is the signed 32-bit integers except zero)
It seems like you're pretty fundamentally misunderstanding what the mistake is, because you have it backwards. Null is a problem because you can just use it like any other pointer without having to explicitly decide how to handle if it's null; Option does not have this problem because you have to explicitly decide how to handle if it's None. Even if you choose to crash if it's None, that's an explicit operation on an Option itself, not the underlying value. There's no equivalent way to force an explicit decision about handling null; it looks just like every other pointer, which means that the only way to avoid using it like one is to be really careful (which we have decades of empircal evidence showing might as well be impossible to do uniformly).
It is different. Handling `None` in a way that crashes your program is well defined in a Rust function. If you're using `unwrap` or `expect`, the program will crash with a stack trace and an error, instead of running into undefined behavior.
Yes. Its also explicit instead of implicit. In rust (and typescript, swift, haskell and others), you have to opt-in to nullability. By default, functions can't take a null in place of a non-nullable value. And whether a function accepts a T or an Option<T> is part of the signature.
It's not a trade. It isn't "because we got memory safety we have to lose supply chain security". Rust, like every other language, has put minimal preemptive effort into supply chain security. There's recently basic stuff like Trusted Publishing and dependency cooldowns are on the way, but that's it in terms of native features - nothing novel or special, really.
Thankfully the community has built `cargo-vet`, which is basically a best-in-class distributed auditing system.
Rust's standard library is incredibly thin (intentionally so). As a result, you need to use the crate ecosystem. This comes with some downsides.
1. Each crate you depend on generally comes with dozens of its own dependencies.
2. A large number of crates have few downloads. You can use blessed.rs to try an find "trusted" dependencies.
3. Cargo comes with "build.rs" for compile time code execution. Basically, your code (or your dependencies) can run arbitrary code when it first gets compiled.
4. A Github account is required to publish crates to crates.io (this sucks if you don't want to be locked in to another Microsoft system).
These are just a few of the issues I have had with Rust before switching off it.
edit:
Point #4 is personal for me. I have multiple crates published on crates.io and I cannot log in and manage them because I deleted my GitHub account a long time ago. I wonder if someone could create a GitHub account using my name and claim ownership of them...
> Rust's standard library is incredibly thin (intentionally so). As a result, you need to use the crate ecosystem. This comes with some downsides.
This is no different than C++. C++ standard library made so many compromises in the name of ABI compatibility almost none of the library is actually usable for any use case. So people start to quickly add things like boost, abseil, folly, Qt, asio, imgui, doctest etc. There are millions of small libraries everywhere too!
Their CMakeLists files or conan packages also execute random commands and in the case of supply chain compromise they are as vulnerable as Rust. Actually CMake is so complicated that one can hide an exploit a bit better than build.rs.
I don't think it is a good thing either way and both toolchains should implement ways to limit execution and isolate code generation. For the packages we also need to see stronger ownership and signing guarantees. Maybe even a domain-based validation system with TXT-keys against takeovers. Allowing random people to just register and typosquat packages is not a good idea.
That's not really true at all though, even in very complex software it's pretty rare to have more than ~10 external dependencies in a C++ project. People tend to roll their own a lot more, partly because dependency management is a lot more painful and fragmented. Boost is effectively an extended standard library, as is abseil, but the language has got much better at incorporating back features since C++ 2011, but even so, the dependencies tend to be slow moving and fairly stable.
True, you have few external dependencies... but you have random code thrown into your repository in the form of vendored 3rd party libraries, header only libraries, and bits and pieces copied from somewhere. Of course you also get huge kitchen-sink libraries that do everything, so you only need to add one library and have semi-decent functionality for everything you might need. At least those usually have people working on maintaining their usually pretty huge dependency tree -- those they know of. They have the same problems knowing their true dependency trees as everybody else in the eco system.
I have not yet looked at any C++ code base > 1 milliom lines where I did not find at least 3 copies of zlib. Often just the compression or decompression function copy and pasted into a random file. Which version? No idea. Was it patched? Likely. Is there any documentation on how to update this? Absolutely not. Was it easy to find? No, some specialists even rename the functions so that users linking to the system zlib do not get into symbol conflicts. I have heared way to often that it is so much simpler to just copy a class over from abseil, or whatever other library than to depend on it.
Sure, you do not see dependencies, the functionality those provide are still there somewhere though -- either hidden away or in the form of reimplementations. You just do not know... and what you do not know about you can not maintain.
I've never seen a C program use hundreds of dependencies. This is typical in Rust (and Node). I know a few high assurance teams that dropped Rust for this very reason.
They look no different than your usual Rust crate. And their full flattened dependency trees already exceeds hundreds of packages.
C/C++ libraries have much more complex build systems with many optional features shipped inside the library. Just think of curl and how many protocols it supports.
Rust's build system, however, is extremely simplistic and limited. So to have things like multiple backends for rendering, parsing, serializing etc. you have to split your library into multiple crates due to limitations Cargo impose on you. So the full equivalent of curl will be 20+ individual crates.
I think the hundreds of dependencies is overblown due to this effect. I maintain my argument. C and C++ projects are just as complex and vulnerable. CMake and fully binary distribution via Linux package managers just hide their complexity.
I haven't seen hundreds of dependencies in C projects either. But I _have_ seen on the scale of 1s to 10s of libraries and algorithms vendored in (sometimes just a header or 5).
It's also an indirect risk, but I've seen C projects reimplement things that would be a dependency in Rust, and introduce subtle (or not subtle) bugs.
again, I don't really see how 1 and 2 are rust specific; compared to c -- sure, but it's seems unfair: the type of rust software that needs a bunch of random dependencies usually wouldn't even exist in c in the first place; if it would, then it's more of a software quality problem than security
even 4 -- fuck microsoft of course, but other than that: you always need some sort of an account to publish stuff
> Point #4 is personal for me. I have multiple crates published on crates.io and I cannot log in and manage them because I deleted my GitHub account a long time ago. I wonder if someone could create a GitHub account using my name and claim ownership of them...
Why not just make a throwaway account with that username and test it, and if it works, just don't save the password or ever log on again? If it's something you care about personally and it's really been that long, I'm kind of confused why you haven't already tried this rather than just vaguely implying risk that seems pretty straightforward too verify. (It's fine if you just legitimately don't care, but it doesn't seem like it's really a personal issue for you in that case)
Most dependencies in the C/C++ world come with fewer dependencies of their own (at least, an order of magnitude fewer than the average rust dependency).
Perhaps a Makefile could be considered arbitrary code execution, but we've been running Makefiles for 50 years and we haven't had the supply chain issues we see in NPM, etc.
Supply chain risk was always considered in the C/C++ world... think back to Ken Thompson's 1984 paper "Reflections on Trusting Trust" where he questioned if you could even trust your compiler.
Perhaps the main difference between the Rust and C/C++ world is less about the tooling or languages, but more cultural? I don't know, just something to think about.
In languages that don't have a culture of deep dependency trees managed with good tooling, supply chain attacks are perceived as being more difficult or rarer. That may or may not be true. But it is a concern in any case. Rust could have had namespaces to decrease namesquatting. The "no deps younger than N days" thing will help some. Those with this perception would prefer a large stdlib that is well vetted or that they can pretend is well vetted. In practice, if you don't use tokio you are likely not using anything that isn't written by a well known member of the rust community. Tokio brings in a lot... The real fix comes in two flavors, pay to write everything yourself and test it well. Or limit what a bad dependency can do. The latter is difficult in every mainstream language. Austral had a good answer for it, but seems to be dead.
In rust if you can verify a dependency is no_std with no unsafe code and that all of it's dependencies are the same, then it can't get to libc or the kernel syscalls. So any privilege it works with is something you passed it. But that amounts to writing everything yourself in practice.
It's not special in this regard in the language, or even especially so in the available tooling. Nevertheless, the culture in rust is to add many many dependencies. I occasionally use self-professed "small, modern" CLI tools that use ~400 crates (e.g., interactive podcast downloader).
Really annoying when people take 50 year old C code and modern C++ code and just drop them into the same bucket and refer to them as if they're the same thing. The CURL example they give has multiple modern C++ solutions that accomplish the same thing without UB.
I'm a / used to be a C++ programmer for 10 years. I've been lucky enough to work in a company that aims to adopt Rust. I have been working on Rust projects in the embedded space that runs on real-world devices right now for 3.5 years. Slowly but surely, not going into "rewrite every single thing now in Rust" but one component at a time when the project justifies it.
So, tell me what compiler option disables non-modern C++ code? Is there one that enforces that every single variable including stack ones work like unique_ptrs without paying the price?
How about safety checks in std; is there an opt-out style safety checks where I can ensure that I'm not adding random things to a map with the [] operator, the library checks size of vector when I access elements in non-performance-critical code, anybody can use iterators safely without being able to write code that can change contents of a container?
How about std::thread? Is there an enforcement switch that I can only pass in things that work exactly like trivially_constructible<T>s, unique_ptr<T>s or shared_ptr<mutex<T>>s and nothing else?
If those all exist, is there a movement to port many of the core building block libraries to that special compiler including std without being afraid of breaking ABI?
Those are all what Rust developers (who were or still are quite advanced C++ devs, btw, not people who are afraid of using raw ptrs) get freely from the Rust compiler. A lot of "modern" C++ code still contains and, by design, cannot avoid creating unintended and unlimited UB.
Actually use a modern compiler and enable the safety features they ship with
Most of these things have solutions that would take years of work in an existing project so it isn't done
And it takes significantly more effort to write good modern C++ code than Rust code
So Rust wins
But I don't like writing Rust code, I do enjoy writing modern C++ code, the tradeoff is modern C++ can be a tooling nightmare... Try shipping a modern stdlib on an old platform, it is truly infuriating, I don't want to be a build systems expert but I need to be to use a safer alternative.
All those things you mention still have way more gaps in them than the rust compiler. They're just not really substitutes (fuzzing and sanitizing do still have their place in rust, though).
My experience is that unless that is pushed by DevOps teams, and being strict about it, no matter how long a build is broken, eventually they get disabled because there is this critical delivery, and then they are never enabled again.
Any language that isn't copy-paste compatible with C (or a subset of it), wins.
That is the biggest issue, old habits and old teaching materials keep working, a plus, and a curse.
This doesn't change a thing, because Rust is an answer to Modern C++ still being inherently unsafe and not meeting the bar. The best that C++26 has to offer is below the basic guarantees that Rust shipped in 2015.
This is the blind spot that prevents Bjarne from taking significant steps needed for C++ to catch up. He's still seeing C/C++98 as the problem to solve, while Rust sees Modern C++ as the problem to solve.
I do think he does see the actual problem, what he kind of doesn't accept/acknowledge is that in the tradition of "worse is better", most companies don't care what static analysis are out there, and that university professors have no intention to change for teaching C++ as it was taught in the 1990's.
The problem of TypeScript, is that you can still write JavaScript with all the WATs, same applies to any language that tries to be TypeScript for C.
However many of us actually think that Rust is also not the answer for everything, there are plenty of safe languages that could be used instead of C, C++, Rust for plenty of scenarios, and aren't because of cultural issues.
Because that is how the real world works, regardless of many of us get annoyed to have people coding in C with C++ compilers.
Beautiful modern C++ unfortunately only exists in conference slides, recent C++ books, and top performer teams.
My main use for C++ outside hobby coding, is to integrate native code into managed runtimes, most of the time the code looks closer to C with Classes than anything past C++11, even if it was newly written yesterday.
and Ryan asked Bjarne about memory safety. Bjarne brushes it off and says that in almost all cases where we see memory safety issues, they are either
1. Being written in C style C++ and not using "Modern C++"
2. Being written in C
He then goes on to say say that Modern C++ and where it is necessary, hardened libraries, go a long way to making these problems non issues. I'm not a C++ guy, so how much of this is true? What do the C++ developers think about this?
I've postd the whole message if people would like to read. It's about 46minutes into the video
Ryan: One thing that I think C++ is uh infamous for is kind of like memory safety issues or kind of foot guns that
exist there.
Bjarne:
I'm so tired of that. Um I haven't had those problems for years. Um, and
somebody did a a study of the obvious problems with buffer
overflows and um people hacking in using that kind of
stuff and uh almost all of the uh these cases when
people writing C style code or in C and uh Herb Server has a a talk with
with actual numbers and they they are quite significant. It's it's sort of
that kind of problems more than 90% are for people that don't
write modern C++. They they use raw pointers to pass
things around without um the number of elements. No fat pointers, no spans.
um you you have them in C++. You can use them. You can use uh vectors. We have
hardened libraries. Everybody has hardened libraries that that does the runtime checking. Uh Apple has it.
Google has it. Microsoft has it. It's just not standard till now. C++ 26 has a
hardened option that are standard. uh and the work I'm doing on profiles will
give you a way of guaranteeing that you don't do the stupid things.
Um so anyway, uh fundamentally
theoretically the problem was solved many years ago and people just do what
they've always done and get the problems they've always had. And uh that makes me
sad and uh it's one of the things that makes me work on uh coding guidelines
and on enforced profiles and on education. I mean education is one way to solve the
problem. Is there a way to get the compiler to just prevent people from
doing all those risky things? And is that enabled by default in modern C++ today?
No, but it should be. I'm proposing that for C++ 29. Uh the simpler versions of
that should have been in in in uh C++ 26, but there are still a lot of people
even in the C++ standards committee that are very devoted to uh their old code
and their old ways of doing things. Um there's people who says you should only
standardize what is common in industry. But when the bugs are common in
industry, you should do something else. The standards committee is a a topic I
If these hardened libraries were as good, we wouldn't have blog posts like this[1], from the android team last year.
> We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code
Maybe the android team could have gotten the same benefits by simply auditing and modernising their C++ code? I'm not convinced. Google has some amazing engineers. They've been using hardened standard library variants for a long time - much longer than they've been part of the C++ standard. If google is still getting large security benefits from adopting rust, I think the benefit in rust is real and Bjarne Stroustrup is wrong.
First of all, Rust is default safe. In C++ developers always trade performance for safety, in Rust they just swallow the penalty (which is often still performant enough). C++ code will often not be as memory safe as it could because someone decided to not use particular checks (like compiler-driven integer overflow checks).
Secondly, Android C++ code is not particularly high quality, also when it comes to memory safety. A lot of it is also quite old.
I would consider it your average massive project, not a masterpiece coded by amazing engineers.
Thirdly, it has a massive target on its back and is under attack by pretty much everyone. They have to use whatever they can to keep up with the attackers.
Several companies have these issues and approach them in different ways. Rust is a very attractive approach for developers, since it’s just another programming language. It’s also quite ugly, people complain about its complexity and is unfortunately suffering from dependency explosion.
I hope it’s a stepping stone to something better.
> In C++ developers always trade performance for safety
A "trade" implies care which isn't actually taken. What WG21 does is they assume that safety costs performance and so they throw away the safety hoping that this means they get performance. They don't measure, which is why you get to see first Herb Sutter explaining that C++ doesn't do bounds checks because they're unaffordable (notice he presents no data) and then a few years later Herb Sutter explaining that the latest C++ will offer bounds checks because they're actually affordable after all (now Google has collected the data)
In most cases it's much worse than the bounds checks, which actually did have a small cost, it's often net negative to throw away safety, C++ chose the less safe and slower option, assuming that this "trade" exists when it doesn't and if they'd measured they'd have seen the news before making the decision.
> First of all, Rust is default safe. [...] in Rust they just swallow the penalty
The borrow checker runs at compile-time, not run-time. Safety doesn't slow down your code except in a few small, specific ways like array bounds checks and UTF8 validity checking - but these checks also happen in unsafe rust too. The overhead is also mitigated by some of rust's other choices increasing performance. (For example, rust uses noalias everywhere, has larger codegen units by default and a better, faster standard library).
There was a really great analysis a few months ago looking at the performance impact of rust, C++ and hardened C++. They patched the compiler to see what happened when all runtime safety aspects were removed - and the result was about a 2-3% improvement. Measurable for sure, but nothing to write home about.
> Secondly, Android C++ code is not particularly high quality, [..] Thirdly, it has a massive target on its back and is under attack by pretty much everyone.
Most code isn't particularly high quality. But I suspect google has better resources and processes than most C++ dev teams. As for security - just about all code is a target now that LLMs can find vulnerabilities so easily. I want all the software on my computer to be hardened against attacks that can be found and exploited in under $5 of compute.
> [Rust is] also quite ugly, people complain about its complexity and is unfortunately suffering from dependency explosion. I hope it’s a stepping stone to something better.
As Stroustrup once said, "There are only two kinds of languages: the ones people complain about and the ones nobody uses." It's a good sign that people are complaining about it. But otherwise I agree - I look forward to seeing how rust's borrow checker inspires new languages going forward. There's a lot more good ideas in the programming language space that we haven't scratched.
However, there are also a number of other threads on /r/cpp where you can read about people's opinions. https://www.reddit.com/r/cpp/comments/1rsmw5j/c26_safety_fea... is one sort of recent (three months ago) thread that I remember having quite the discussion.
My take (which is, given that I worked on Rust, a bit biased, but I intend to be truthful regardless) is that there are some folks who agree with Bjarne, but also many who do not.
> He then goes on to say say that Modern C++ and where it is necessary, hardened libraries, go a long way to making these problems non issues.
I'll believe this when he can actually point to non-trivial, real-world C++ codebases that have managed to avoid having memory unsafety following these techniques. "It's technically possible for this issue to be avoided" is a lot easier to say than it is to actually make work in practice.
If Apple and friends have a secret recipe for avoiding C++ memory vulnerabilities, maybe they should start using it to avoid stuff like this: https://nvd.nist.gov/vuln/detail/CVE-2026-20700
The recipe is tame C and C++ as much as possible, on the language level, toolchains and hardware memory tagging, following by writing new code in something else like Swift.
See Meet with Apple, security event.
Naturally they aren't going to throw away LLVM, DriverKit or Metal Shading Language, so there is a compromise there.
My point is that there are plenty of smart people touting various recipes for safe C++, but somehow vanishingly few instances of actually safe C++ codebases. It's hard not to feel like the claims that C++ can be made safe are mostly being made from an abstract theoretical viewpoint and not a pragmatic one, because even the companies with the most resources or the smartest people don't seem to be able to pull it off.
Agreed, however I would vouch it is a matter of culture beyond anything else.
Dennis Ritchie had this to say about C,
> Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions.
So lint aka static analysis, exists since 1979, and yet in 2026 one still has to advocate for stuff like clang tidy to be used.
Now you can argue that the right way would be to fix the language, not outsource to a linter, yes although the same could be told about clippy versus improving Rust.
Just like even though C++ frameworks always had the option to have bounds checking enabled, it took until C++26, under industry and government pressure, to make it officially part of the standard.
Community culture is a big deal, and hence why you don't see everyone using unsafe (or similar) all over the place in memory safe languages, and it is a big deal to even improve C and C++ safety by at least adopt the tooling that is already there.
About twelve months ago, Bjarne wrote a paper named "21st Century C++" for WG21. In that paper Bjarne begins with a 10 line C++ listing which he says is equivalent to a fairly trivial awk program. It's a needlessly bad program which in fact has Undefined Behaviour, as I pointed out here (on HN) at the time.
So when Bjarne says he hasn't had this problem, you can take that one of these ways:
1. Bjarne doesn't understand that "this problem" includes all UB, meaning he is grossly incompetent, you should disregard his opinion about this stuff.
2. Bjarne is deliberately lying to you, he knows he still has this problem but for whatever reason he wants you to believe he fixed it. You should disregard his opinion about this stuff.
3. Bjarne is too ignorant to even recognise that his program has UB, once again you should disregard his opinion about this stuff.
Unsafe is not necessary to trigger UB in case no_std is used. Nor if one of the soundness holes in the Rust programming language itself is encountered. Nor if there is UB in one of the libraries used as a dependency by the library you are using. Nor if there is UB in the Rust standard library. Which has happened many times, since the Rust standard library is full of unsafe.
Rust also requires libraries to be safe regarding unsafe, no matter what kind of insane input that is given to the library and that would otherwise potentially be security issues. Which is too difficult for many library authors.
And unsafe in Rust is so difficult that many library authors throw their hands up, use Miri, and hope for the best. Even though Miri, all respect to it, has bugs, probability-based testing and other limitations and issues.
If you are interested in a more nuanced take on what makes unsafe Rust both valuable and difficult, check out my blog post on the Oxide blog: https://oxide.computer/blog/iddqd-unsafe
I directly tackle the concerns you mentioned, and as a followup I'm actually working on formally verifying the library as well (I've had some success and will publish an update regarding this).
Ooh, cooll to hear you got some uptake on the call for formal methods help! Or did you end up figuring it out on your own? Either way, looking forward to the followup!
I'm caught somewhere between interpreting this as "C is all we need. git gud" and "rust hurt me and I'm still mad" and I'm struggling to see any other option. It's an unfocused rant that seems keyed off "rust" and little else.
In broad strokes it's correct, this stuff happens and it's hard to be correct all the time. But are you trying to make a point? Or just ranting?
Also that linked issue was considered a CVE and is fixed (as the article says).
I see his reply as "people say Rust is safe, but Rust just pushes it under a rug and pretends it's safe when it's still all there - just in a dependency"
> Unsafe is not necessary to trigger UB in case no_std is used
I have no idea what are you talking about, no_std is just completely irrelevant here.
> Nor if one of the soundness holes in the Rust programming language itself is encountered
Have you actually examined those soundness holes? It is basically impossible to hit them without writing code which is meant to hit them.
And this is also noted in a footnote.
> Nor if there is UB in one of the libraries used as a dependency by the library you are using
If we treat a Rust program globally, this is kinda true. A more true statement will be that UB cannot happen without unsafe code somewhere, including in dependencies (and the original statement can be interpreted as saying that).
But the true power of unsafe is that it's local. If you've reviewed a library and its unsafe is sound, you can ignore it for the rest of the calculation. And of course, the more people review a library the more likely it is that it is sound.
> Which has happened many times, since the Rust standard library is full of unsafe
And here again the post's point stands: many CVEs in std are artificial, you can't exploit them without writing a program that is meant to be exploited. Such thing will never be a CVE in C/C++'s std.
> Rust also requires libraries to be safe regarding unsafe, no matter what kind of insane input that is given to the library and that would otherwise potentially be security issues. Which is too difficult for many library authors.
That is true, that is in fact the post's point: that if they fail this, a CVE will be filled, even if exploitation is just not possible realistically.
But there is a very simple solution for library authors: don't write unsafe code! You don't need to, the vast majority of times. And if you do not have the knowledge (which indeed is more complicated than in C/C++) how to not have an unsound API, then you just should not write unsafe code.
> Nor if one of the soundness holes in the Rust programming language itself is encountered.
imo one of those soundness holes is caused directly from trying to prevent UB - integer overflows. It is inconsistent in Rust what happens in that scenario depending on compiler flags, which basically just makes it UB for any given piece of code. And, unfortunately, default release mode behavior is unsafe.
You seem to have been misinformed. Rust panics on overflow in debug mode (or always if you toggle a compiler flag), and has a guaranteed wrap-around in release mode. In no case there is UB.
No, that's exactly what I'm aware of, and is exactly the wrong behavior I'm talking about. "Sometimes crashes, sometimes two's compliment" are extremely different behaviors, and not meaningfully different from just saying it's UB. It should always panic, with no way to disable it. The wrap around in release mode is simply bad behavior. It can't be relied upon (because it panics in debug), and it's not useful behavior for nearly anyone's logic (wrap around almost never is logically correct behavior)
It lets Rust claim to be UB free without delivering the actual value of being UB free. You still can't rely on a given behavior because it doesn't have one behavior, it has two, and the two behaviors are wildly incompatible with each other.
It's surprising and potentially buggy behavior, but that's very different from undefined behavior. To such a degree that I think you honestly might not understand what it means, and what the risks are around undefined behavior, especially in the presence of an optimizing compiler.
As a starter / refresher perhaps, both of these are perfectly permissible and happen in practice with UB, but never with "wrap or panic" / "implementation defined" behavior: https://mohitmv.github.io/blog/Shocking-Undefined-Behaviour-... This kind of thing is an example of the "time travel" stevekablanik is referring to, stuff that is literally impossible as written, that absolutely no human would consider to be a reasonable execution of the code, but occurs regularly with UB.
> and not meaningfully different from just saying it's UB.
It is extremely meaningfully different, because the range of options of what can happen is bounded in one case (either two's compliment wrapping, or panic) and unbounded in the other case (literally anything is allowed to happen, including time travel).
This is "implementation defined behavior" in C and C++'s terms, not "undefined behavior."
Which definition of UB are you using regarding that? Behavior changing based on configuration does not seem like UB, at least if none of the configurations allow for UB.
I'm not convinced this is true. Otherwise, it does not bode well for Rust code because any type safety glitch will be considered a vulnerability. This would be really challenging for Rust developers because it goes beyond unsafe Rust code. You can easily have unexpected panics because your types do not enforce invariants as you expect. If a library has such a bug, is this a denial-of-service vulnerability in the library? Rather than dealing in absolutes, I would say that it's impossible to tell in isolation. If applications do not misuse the library in ways that triggers the panic, probably not, and treating this as a vulnerability just results in pointless noise.
Determining the impact of library bugs can be really hard. For example, some functionality might be so broken that it's simply impossible to use correctly, so a buffer overflow on top does not make a difference. Or a buffer overflow vulnerability triggers consistently during system boot, so that you never get to the login prompt. These can hardly be considered vulnerabilities. On the other hand, we have clear buffer management bugs, where we must expect that there is application code out there which specifies tight buffer bounds and requires that the library stays within that buffer. (Rust should help here, at least out-of-bounds accesses should turn into panics.) But most bugs are unfortunately somewhere in the middle. Tools like Debian Code Search can provide some evidence. But in the end, it's more subjective than I'd like it to be.
On the extreme end, we have compiler soundness bugs. I'm a bit of worried that I'm hitting any of those when I'm tweaking the types until the compiler no longer complains. Beyond the basics, I really don't have a grasp of Rust's type system rules. But I suspect they very difficult to hit by accident, and even if I do, the code must be miscompiled in meaningful, but difficult-to-notice way. All that seems rather unlikely, which is why these bugs aren't treated as vulnerabilities.
I really think we need some corrective factor (such as potential implication impact) when determining whether toolchain bugs are vulnerabilities.
But it is. It is true that Rust libraries could take this position of "any API misuse causing vulnerability is a CVE" more to the extreme, currently it is applied to memory safety but it could be applied to panics as well. However it is still true that pretty much all Rust libraries treat API misuses that cause UB as a CVE, and pretty much no C/C++ library does that, and that inflates the number of Rust CVEs.
> On the extreme end, we have compiler soundness bugs. I'm a bit of worried that I'm hitting any of those when I'm tweaking the types until the compiler no longer complains. Beyond the basics, I really don't have a grasp of Rust's type system rules. But I suspect they very difficult to hit by accident, and even if I do, the code must be miscompiled in meaningful, but difficult-to-notice way. All that seems rather unlikely, which is why these bugs aren't treated as vulnerabilities.
Rest assured that you are much more likely to hit a miscompilation in your compiler's backend, and that it is much harder to detect.
> Rest assured that you are much more likely to hit a miscompilation in your compiler's backend, and that it is much harder to detect.
The LLVM provenance bug is a really nice example. The Rust which tickles this bug (LLVM emits nonsense, claiming that two integers a and b are different but then calculating that a - b == 0...) is fairly clear, you wouldn't write it by accident but it's obvious what it should do, and unsettling to discover that the bug isn't in Rust's compiler frontend but in LLVM.
You can write equivalent C or C++ to show the bug with Clang - but when you try to write it you'll struggle, not to reproduce the bug per se, but to stop writing Undefined Behaviour, which invalidates your bug report because the LLVM devs will say "This is UB, working as intended". The non-UB reproducers are much more elaborate than the safe Rust was.
So e.g. if we make a pointer to thing A, which we then destroy, and then for a pointer to thing B, and then we compare these pointers, even if the address which will be the only bits making up this pointer in hardware was identical, a language could choose to say these pointers are not the same (Rust says they compare equal but that's up to Rust). LLVM is equipped to do this optimisation. So far, not a bug, though perhaps not what you expected...
However everybody is pretty sure that we don't want provenance for other value types. It's troublesome for pointers but we're used to it and it unlocks important optimisations, but for every other value type it's just extra trouble. So Rust's provenance model says only pointers have provenance, and proposals for C and C++ likewise. If we ask for the address from a pointer, making it into just an integer, it should not longer have provenance.
But, LLVM doesn't really track whether a value "is" pointer or not per se, so it ends up applying that "they're not equal" optimisation to the integers we've made from pointers, even though the integers are definitely equal and we're about to do a subtraction to prove it. Bang.
>Otherwise, it does not bode well for Rust code because any type safety glitch will be considered a vulnerability.
I mean, this is basically true. And it goes beyond type safety - there have been CVEs filed against the Rust stdlib for TOCTOU problems of a kind that the C++ stdlib is absolutely replete with (often the exact same ones in the exact same places, to the extent that comparable APIs exist) which ended up being fixed quickly in Rust and largely ignored in C++, if anyone bothered to file in the first place.
For sure does create headaches for those who need to categorize CVEs by impact, but on balance I don't think it's a bad thing for the ecosystem. Creating a culture that wants to fix soundness issues rather than mark them as WONTFIX with a line of documentation is a core principle and value proposition of Rust in the first place.
Just want to remind everyone that only 1% of vulnerabilities are memory related in the average Joe's code.
And only 20% of memory related bugs are use-after-free which the borrow checker fighting is for.
And 100% of the use-after-free exploits were to gain admin rights on an already hacked Windows (all windows) computer.
So for the vast majority of people the borrow checker adds nothing.
The vast majority of memory safety bugs (extreme pro level, super hard to exploit, only worth it in massively adopted evil outer world facing software) can be fixed by using C++26 with array bounds checking and forced initialisation.
These last two things that Rust forces catch 70-80% of the memory problems the borrow checker only 20-30% only use-after-free.
Most problems by far for normal developers are supply chain attacks, exposing api keys, remote code execution, wrong input validation, wrong auth-flow.
You're reading the CVEs of sudo and ssh and think your code will be hacked like that.
PHP is memory safe and still many people hack wordpress plugins.
Hrmm. I don't think there exists a set of compiler flags that will just make an existing C++ (or, worse, a mixed C and C++) project safe to the extent that you suggested. The STL hardening flags don't help for ordinary arrays that aren't accessed via smart pointers, and they don't help code that uses a pointer+offset style of access. As for UAF, nothing in C++ comprehensively prevents you from accessing an invalid stored reference even if you have cranked up the hardening mode to DEBUG. Rust, on the other hand, affirmatively prevents that.
You can also write inline assembly in C++ and then it's not safe.
But no developers working on projects that have been so ultimately battle tested that only memory safety issues remain do that. Professional C++ developers use RAII and containers. If you use raw pointers or raw arrays in C++ you will get 200 code reviewers lecturing you. You will never be able to for long.
> Just want to remind everyone that only 1% of vulnerabilities are memory related in the average Joe's code.
Unless your point is merely that average Joes write such terrible code that you don't even need memory safety issues to exploit their software, [citation needed]
Most memory bugs in Chromium are in V8, either entirely in the JIT or at the boundary with C++. Rust wouldn't help here because the borrow checker can't see through these boundaries, and it's precisely this opacity where the developers also lose track of things.
Which isn't to say Rust wouldn't have caught many of the other memory safety issues, but 75% is horribly misleading.
In Chromium which is the condom of the internet, already millions of developer hours of the most highly paid developers have spent their days trying to make it water tight. This is not your average software project.
My understanding is that they claim that the average Joe writes code in a garbage-collected memory-safe language.
Which is... true? but irrelevant. Such applications are not suggested to be ported to Rust. Of course, some people still do that, because they like Rust; but that's their personal choice.
PHP is garbage collected for reference. So rewriting wordpress plugins in Rust would not make them more secure but rewriting HAProxy or Nginx would? It's delusional.
If the class of bugs WordPress has is different from the class of bugs HAProxy/Nginx, eg SQl injection vs buffer overflow, then why is a different mehtoyof fixing "delusional"?
The point is that memory issues are a smallish number of issue compared to the larger ecosystem of vulnerabilities, and choosing to port everything to Rust is like over-optimizing. Well, that’s my 2 cents.
For a language as ugly as Rust, my thought is that people should actually be using Ada, and have a mathematically provable correctness angle; not just a replacement for C/C++ with memory safety.
Perhaps. But what percentage of exploits are actually zero days versus, say, 10 days or 100 days?
Most exploited code probably exists in the application layer in a high-level, memory safe language. I would wager that but I don’t have time to cite ten papers on HN.
Rust and Ada are about equally safe, both have advantages and disadvantages. Perhaps you're thinking about SPARK ADA, but that's a different kettle of fish.
It's a bit like saying you should program in C, because formal verification tool X generates C code hence C is safe.
Rust and non-SPARK Ada are not equally safe. Ada is unsafe in the presence of data races, and also has runtime checks that slow it down, or you disable them and then it's even less safe.
I do not believe that I agree, and I am not sure about all of your numbers.
The borrow checker does add something, but it definitely costs something as well in multiple ways, also in terms of how it is done in Rust and at a programming language design perspective.
It would be very funny if you were batting for Rust, and just having a laugh at others here.
a rule of thumb i follow is that the second someone starts comparing or talking about the number of CVEs, i just ignore whatever they say next. its hard to think of a more useless metric than "number of CVEs", especially now.
(edit: the people disagreeing are encouraged to share how you use "number of CVEs" to inform your decision making)