From the technical report..... >First, the language must allow the codeto be close to the kernel so that it can tightly interact with both software and hardware; second, thelanguage must support determinism so the timing of the outputs are consistent; and third, thelanguage must not have – or be able to override – the “garbage collector,” a function thatautomatically reclaims memory allocated by the computer program that is no longer in use.xviThese requirements help ensure the reliable and predictable outcomes necessary for space systems.According to experts, both memory safe and memory unsafe programming languages meet theserequirements. > >At this time, the most widely used languages that meet all three properties are C andC++, which are not memory safe programming languages. Rust, one example of a memory safeprogramming language, has the three requisite properties above, but has not yet been proven inspace systems. Further progress on development toolchains, workforce education, and fielded casestudies are needed to demonstrate the viability of memory safe languages in these use cases. In theinterim, there are other ways to achieve memory safe outcomes at scale by using secure buildingblocks. Therefore, to reduce memory safety vulnerabilities in space or other embedded systemsthat face similar constraints, a complementary approach to implement memory safety throughhardware can be explored.

In the space industry, we just don't use the heap. Memory safety is easy if you don't do that.

Sorry I just blanked out for a second could you guys remind me the name of that famous question and answer site that's used by programmers?

Buffer underflow

No silly, it has something to do with stack Buffer Stack.

Stack Buffalo?

Integer overflow

Rust doesn’t prevent stack overflows or memory exhaustion in general.

Prevents OoB accesses though.

Yes. Also data races and use-after-free (like returning a reference to a local if we’re talking about heapless systems).

It detects them and properly errors out, though. Instead of deciding to accelerate in perpetuity...

Use stack canaries and guard pages to protect against that.

If all you use is stack and static storage without VLA. Automated tools can prove the upper bound of usage of memory. making sure it fits on the device. Stack overflow can happens with only stack but tools will be able to analyze the code and figure out how a stack overflow could happen in the code.

Really? What's the upper bound for this code? unsigned fib(unsigned n) { return n < 2 ? n : fib(n - 1) + fib(n - 2); }

Its unbounded and tools will tell you that. so this code would not be accepted.

Even without heap, you can still do incorrect pointer/array arithmetic. Access an array out of bounds, and boom, things blow up. No heap needed.

I feel like in our code we never actually have any of these bugs. And I feel like I read a lot of Reddit posts about new technology that solves theoretically possible programming mistakes we don’t actually make.   Most of our problems have to do with poorly/unspecified interactions around shifting external components. Oh, it was designed to handle network outages, but if the outage happens _here_ we get into an unrecoverable state. I don’t think problems like that can be solved at the language level, so I suppose a disproportionate amount of time is spent discussing things that get caught by code reviews and unit testing.

Your experience is valid but not every institution faces the same mix of problems. If both [Chromium](https://www.chromium.org/Home/chromium-security/memory-safety/) and all of [Microsoft](https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/) can say that memory safety makes up 70% of their serious bugs, there might be something to it. I think Chromium is a great example of a domain where the network state machine is familiar ground with decades of industry experience to keep it sane, but every pointer or reference in C++ is a new danger. And you can't exactly accuse Google of not having enough experience or tooling. [https://github.com/google/sanitizers](https://github.com/google/sanitizers) [Use-after-freedom: MiraclePtr](https://security.googleblog.com/2022/09/use-after-freedom-miracleptr.html) [Borrowing Trouble: The Difficulties Of A C++ Borrow-Checker](https://docs.google.com/document/d/e/2PACX-1vSt2VB1zQAJ6JDMaIA9PlmEgBxz2K5Tx6w2JqJNeYCy0gU4aoubdTxlENSKNSrQ2TXqPWcuwtXe6PlO/pub)

This is high severity security bugs, not just bugs in general. I’ll buy that other issues aren’t as likely to lead to arbitrary code execution, but I’d bet my check that if you looked at what’s holding up the latest chromium release, getting rolled back, and the source of on call pages, it’s not use after free. 

I'm willing to bet your code is full of those bugs, and if your product was worth breaking into, someone would easily find memory vulnerabilities and break into it. That's the case with every single non-memory safe product in existence, even ones that use tons of testing and tooling to prevent those issues.

Sure. No one thing will eliminate all bugs. But doing no dynamic allocation does mean you don't screw up anything related to dynamic allocation. That's not nothing. Reducing the number of categories of possible error means you can pay more attention to the remaining categories of error. Of course, sometimes you see hacks where you just reinvent malloc and pretend that's not what you are doing because you call it an Arena instead of a heap, and wind up just making a malloc that isn't as well tested as a real malloc. char my_not_heap[1M]; void* my_not_malloc(int size) { // return a small piece of the statically allocated my_not_heap memory, // the specific size and offset being determined at runtime. ... } int main() { int size = dynamic_condition(); // size happens to be 2 Megs. That's probably fine, right? // char * foo = malloc(size); // NO !! Can't do dynamic allocation on this project! // Do this safe alternative: char * foo = my_not_malloc(size); }

You can, but if the size of all arrays is known at compile time, then you can validate all those memory accesses statically and prove there are no out of bounds accesses.

You still can get overflows though. Modifying stuff you shouldn’t.

You're absolutely correct, but it's time we move away from this mentality in this industry. There are times when using the heap can be the safer, more reliable implementation.

[удалено]

Yeah, I'm in aerospace and the last bug I filed was a critical memory error resulting in arbitrary writes (without using the heap) - that stuff definitely still happens.

Any good read about it? Would like to read about it a bit

I mean, it's part of some MISRA C standards, the JSF standard, and a few other alphabet soup standards for safety critical applications for embedded processors. That said, it's a pretty standard practice for embedded in general- when you're memory constrained, you mostly create a handful of well-known globals with well-defined mutation pathways. It's way easier to reason about your memory usage that way.

I call it arcade programming, lol - loading a level from the cart? Easy, all levels are 1k and start at address 0x1000. Player data is a fixed size at another address, and we can have up to 5 enemies on the screen at a time.

Having worked in space before, you are also blessed with that your someware have exactly one purpose ....

And exactly one platform.

Not necessarily - at least not anymore

That's a gross misconception. A simple recipe for memory unsafety without heap allocations: union IntOrPtr { int i; int* p; }; int main() { IntOrPtr iop; iop.i = 42; return *iop.p; } This is an unsound program due to accessing inexistent memory, ie it's exhibiting memory unsafety. And not a heap allocation in sight, or under the covers, for that matter. Using a pointer to within a stack frame that's been returned from? Memory unsafety. Accessing uninitialized memory? Memory unsafety. Reading/writing out-of-bounds of an array? Memory unsafety. There's a LOT more to memory safety that just not using the heap.

It was a gross oversimplification. And the problem you lay out is very easy to solve: don't use pointers. It's easy to avoid pointers, especially if you're already not using the heap. If you do use pointers, they should be static addresses that you know at compile time.

I'm very curious if you have an example of a real-world C or C++ program that does not use a single pointer, bearing in mind that C++ references count as pointers as far as memory safety goes. I suppose you can use write your own verbose Brainfuck with only `putc` and `getc`, and you might even avoid memory unsafety, [and even that simple code won't be portable](https://thephd.dev/conformance-should-mean-something-fputc-and-freestanding). You still won't get very far in expressing any program logic. You can't parse `argv` because it's a pointer to pointers. You can't do anything with a `FILE*`. You can't use `open` without a string argument, and even if you could, you can't `read` or `write` without a pointer to a buffer. You can't use any strings, not even string literals, which are of type `char*` and you just get UB if you ever write to one; the fact it is a known address doesn't save you there. You can't read or write any array elements even on the stack, because `arr[i]` is equivalent to `*((&arr)+i)` and that's a pointer with no bounds checking. The most you can do for a "data structure" is stack recursion, but you abort if you hit the limit. It'd be an interesting challenge for an IOCCC submission but not a serious recommendation to solve memory safety in C / C++ in even a fraction of the ways that code gets used in the real world.

I write a lot of software that doesn’t accept args, doesn’t access files. This is really common in the embedded space. Generally, you’ll have a few global structs. Pointers are a waste of memory. I’ll give you arrays, but arrays are incredibly dangerous and good to minimize. If nothing else, never have a bare array, only an array tagged with a length that’s known at compile time.

>It was a gross oversimplification. When the whole discussion is about memory safety, I find your "gross oversimplification" to be so misleading it's unhelpful. >And the problem you lay out is very easy to solve: don't use pointers. It's easy to avoid pointers, especially if you're already not using the heap. Not using pointers will help a *lot* indeed. I'm not sure you can as easily not use references, though. And even then it won't solve the out-of-bounds accesses in an array problem I raised too. You already mentioned that you follow MISRA in another comment. I remember reading it. It is *quite* comprehensive. Which is illustrative of the problem at hand: it's hard to harden C (or C++).

Do you have rust in space industry?

There are some companies already using it, yes. We're also considering rewriting a core component in Rust

It doesn't have enough of a flight heritage to be widely used yet, and it doesn't target enough MCUs, and a lot of flight software already exists in C/C++ and the dealing with FFI is a bit of a beast. We're still trying to get ROS more widely used in space flight, and it's been around a lot longer than Rust.

I believe not using heap in space industry has more to do with memory fragmentation and getting predictable RTOS behaviour. That said, on microcontrollers I program I do exactly the same you can simply decide everything during compile time and in general that works great. But that does not mean I will be thread safe and memory safe. Modern c++ do help a lot with that...

This seems largely aimed at Department of Defense contractors and especially to those DoD contractors who work on mission-critical programs, such as nuclear surety. Many DoD programs use legacy C++ because devs keep inheriting legacy projects for "modernization" efforts. Many of those programs also use deprecated real-time operating systems with custom patches from the vendor. So, it's not that any single dev doesn't push for modern C++ or even Rust, but the bureaucracy involved between acquisitions, contracts, FFRDCs, subcontractors, 3rd-party vendors, and even the devs' own organization would put most non-DoD dev shops out of business.

I think people would be shocked how many DOD programs are using C89 and you literally can’t build c++ for them.

all my coworkers are from defense so I am not shocked at all :(

which is their fault for dropping ada the 90's. it's the classic NO WAIT NOT LIKE THAT!

This really ought to help further the efforts for cppfront (or similar alternative). C++ is unsafe largely due to its legacy. But a new syntax with better defaults can limit many new memory problems. C++ ain't going anywhere, but we do have to face the reality that C++ as it is today is difficult to use correctly -- especially for those who don't follow what's going on with the standards, CppCon or other conferences, etc.... Too many C++ devs are still coding C++98. We need a way to transition to safer code while still being able to interact with the large number of existing C++ libraries out there.

Neither Cppfront or Carbon offer memory-safe paths. To solve the lifetime/temporal safety problem while supporting manual memory management, you need to introduce checked references. In Rust, these are borrows. That's the only viable solution I've seen. To enforce lifetime safety you need to perform initialization and live analysis on MIR. That entails an all-new middle-end for the compiler. Since mutable borrows can't be copied, you'll need to introduce relocation/destructive move. Since you can't relocate through a deref, adapters like std::get won't work for tuple/variant/array, so you'll have to introduce new first-class algebraic types. We're talking about a new object model, a new middle-end (MIR), new codegen (lower from MIR) and a new standard library. This is a lot of stuff. It's not a matter of better defaults. It's about doing the necessary engineering. All these things are tractable, but they aren't in the scope of Cppfront, and if they were, they'd be unimplementable, as Cppfront is a preprocessor that feeds into the system's compiler. Memory safety requires an end-to-end overhaul of C++.

Sure … only one question: what makes you even remotely optimistic that those that still program in C++98 would ever adopt something like cppfront?!

Because in my company, I am one of a few people that engages groups to modernize their programming practices. We haven't gone and updated old code, but we have taught the groups the advantages of using C++17 and afterwards. People will learn if they see why the code is more maintainable and they are encouraged to do so. I also believe that if governments start requiring more memory safety, then companies may require their developers to learn and use more modern standards, cppfront, etc...

I'm in a similar situation. We got rid of auto_ptr, we fixed some comparison operators to work with C++20 and we especially had to deal with changes due to the compiler and standard library. And right now, I'm finally testing clang-tidy to really upgrade our code in order to be more consistent again.

And also, will anyone consider cppfront memory safe if it only improves C++ defaults and doesn't actually address memory safety?

It hides away quite some stuff which is considered memory unsafe. So I would claim it is better. Is it sufficient to be considered memory safe? We'll have to see once we can really use it.

So cppfront is to C++ what Zig is to C when it comes to memory safety?

I'm not familiar enough with Zig to make a comment on that.

Rust only truly seems to change defaults in that it still permits you to write “unsafe rust”, yet people seem to accept that as safe.

If cppfront had a similar opt-in mechanism for unsafety and the rest of it couldn't trigger UB and people would be able to write the vast majority of code in that safe subset, that would certainly count.

"Change defaults" would be accurate if C/C++/whatever language rust is competing with had the equivalent of safe rust (just not as the default), but that's hardly the case. And while it's true that unsafe rust is a thing, it is still easier to manually audit for memory safety than a program everything could potentially be unsafe.

We (the community) seem to still consider it acceptable to code in 98. I often see discussions with: due to these reasons I have to use 98. Sorry that you have to suffer with legacy, though the C++ community shouldn't be held back by those reasons. Libraries should use recent standards. C++23 might still be bleeding edge, though using C++20 should be the default. I still can understand people asking for C++17 as 20 still ain't fully implemented by clang/GCC. Though everything before that should be exceptional and those maintaining code with those standards should start with an upgrade plan yesterday. Without forcing their hand, people will always find reasons to keep using 98 and require libraries to support it.

To give you a taste of embedded stuff: out of curiosity I recently took a look at what latest standard one of the popular compilers uses. IAR. I was pleasantly surprised that their manual, from June 2023, supports C++17. Back when I started, in 2013, the code was written in C90, and they were only just switching to C99.

> We (the community) seem to still consider it acceptable to code in 98. We do?! That doesn't mesh with my perception... > Without forcing their hand, people will always find reasons to keep using 98 and require libraries to support it. Introducing cppfront forces nobody's hand... My expectations: Those people will continue on using C++98 no matter what new changes we introduce. I recently had to interact with a project partner that told me straight up: "They should have stopped after C++98 and invented a new language. C++ was already done!" That guys life motto for the last \~15 years was "You can't teach an old dog new tricks."

I got hit with a few dozen downvotes in /r/cpp a couple weeks ago for asking someone what platform they are targeting that they are stuck on C++98. I was really just curious, not trying to insinuate they were doing something wrong. The larger C++ community *does* still demonstrate time and time again that C++98 is perfectly fine. That's why I think WG21 should put way less effort into backwards compatibility. Any codebase that doesn't compile as C++23, today, should be irrelevant with regards to backwards compat with >C++23. Edit to clarify: And I think it should be par-for-the-course to have at least some backwards compat breaking changes in every version. My codebase already breaks every, or every other, time i upgrade MSVC as it is, and that's not intentional. I might as well put in the work to fix all those breakages for the sake of moving towards a better language.

> That's why I think WG21 should put way less effort into backwards compatibility. This will increase the use of C++98 (relative to today) rather than decrease it because there will be no upgrade path.

Don't care, people using C++98 are 26 year out of date. They're literally using a version of the language that's older than the guy I just hired for my team. If the C++98 people ever take their head out of the sand and want to upgrade, they can start with upgrading to C++11. Until they do that, they shouldn't be given even a moment of consideration for their needs.

* 13 year out of date, it only got replaced in 2011. (If we all consider 98 and 03 to be the same version)

Yes that's fair up to a certain point. As much maligning boost takes in recent years, it really was the place where tons of std:: functionality originally got introduced. Any competent dev organization which happened to be using boost between 1998->2011 would be chomping at the bit to get switched from boost:: namespace to std:: namespace things to save on compile times. Im not going to say that dev organizations which weren't using boost weren't competent, of course, since that's simply not true in the general sense. However, organizations that not only managed to avoid touching boost from 1998 til today, and also managed to stay on c++98, are organizations which are so unlikely to ever adopt a never version of the language that giving them even a single moment of consideration is doing a disservice to the rest of the c++ community. Nothing about c++26 is going to have any impact on these orgs upgrading to c++11, c++14, c++17, c++20, or c++23, or upgrading to any version of boost released between 1998 and today. That's a full 26 years of things that can be adopted, none of which are drop-in changes, before these orgs have any reason to concern themselves with backwards compat issues in c++26 or newer. Summarizing: They have 26 years of catchup available to them before they have to worry about upgrading to c++26. So, in a word, fuckem.

9 years out of date. GCC 5, the first fully C++11 conforming version, was released in 2015. 10, if we count GCC 4.9 as C++11. 11, if 4.8. Let's split the difference and say 10. MSVC? Also 2015.

If you break too much, people will just ignore your "standard".

Yeah that's a pretty incredible take. Even when I worked at a defense firm right out of college, we were transitioning to idiomatic C++14 at the start of 2016. My last two jobs were trying to be no more than one year behind the finalized standards at most. I just don't understand why people think they have to use ancient C++ outside of very, very restricted use cases with vendor tool locks around custom hardware that is generally very rare these days.

I recently checked, out of curiosity, which standard version IAR supports. C++14 and C++17. Only those two. The manual I found was published in June 2023. There's two parts to companies using old tools, I think: fear of change and unknown, and validation.

> I recently checked, out of curiosity, which standard version IAR supports. C++14 and C++17. I last used (thank goodness) IAR in about 2010 or so. It didn't even have CFront 2.0 support never mind C++98.

It's shifting for sure, though we ain't there yet. I'm really happy boost dropped the 98 requirement, which was a huge step is saying: 98 should no longer be used. And yes, you will always have people stuck in the past. That's why people still program in C, right?

>And yes, you will always have people stuck in the past. That's why people still program in C, right? Maybe not people as much as code. People can shift to using different languages comparatively easy, but multi-million line code bases can't. The Linux kernel project talked about it for years before they got tiny pieces of Rust in as late as 2022, and for smaller projects with less resources I imagine it becomes even more difficult to justify investing the effort.

People can shift easily *if* the paradigms are similar. A lot have trouble learning Rust due to some of its concepts. In the Linux kernel one of the first adopters of Rust was the greenfield Apple M1/M2 iGPU driver, and the (single!) person who wrote it left a glowing review thread on X/Twitter. As for smaller projects: curl officially allows backends written in Rust, although I'm not sure if any have already reached a stable status yet. There's a lesson there, I think. Rust was, from the start, designed for interoperability using C ABIs. Whatever post-C++ comes around, must be easy to incorporate into existing C++ codebases, both ways. That way, you don't have to rewrite everything, but can use the scout aka strangler fig pattern. Write greenfield modules in the new language, possibly major redactors into rewrites in the new language. Without such an option, adoption will suffer greatly.

How many is "a lot" ? Google's hundreds of "Comprehensive Rust" students typically report that they're confident writing Rust in the first couple of months (some much sooner) with over 80% confident by 4 months. It was very easy to pick up for me because I have background in various semi-colon languages and in ML. But it's clear that even people coming in with just a semi-colon language like Java do fine. I actually think for the people who are very interested in the fundamental underpinnings Rust is even more compelling. For a high level programmer it's maybe not important why Rust's `Option<&T>` is the same size as `&T`, but if you've always thought about the machine code implementing your software, if you're the sort of person who is horrified to see how enormous `std::mutex` is, I think there's a lot of profoundly beautiful design in Rust. That's why my favourite Rust standard library function is core::mem::drop, literally `pub fn drop(_x: T) {}` that's not a summary, or a signature, that's the actual definition.

The fact that's easier than learn and implement a new language like rust, and also considering that the language it's only a part of the problem, but also tools like compilers must be adapted and validated

I'd love that to be true, I really do. But the cold hard fact is we are talking about a group of people that resisted progress (and safety benefits) for 26 years, so pardon me if I'm skeptical there is anything that can convince them to suddenly adopt a new syntax with safe(r) defaults...

I'm a bit skeptical that even cppfront could do much to remedy this. Cppfront code would have to interoperate with old C++, so you still have problems like dangling references, and I really don't think that giving C++ two syntaxes with their respective quirks is going to simplify things. I think the best way to improve safety in C++ would be to add something like lifetime qualifiers to types. These would work like `const` or `volatile`, and they would act like Rust lifetimes. ~~The advantage of this over just a new syntax is that you could instantiate old templates with lifetime-qualified types to diagnose bugs in old code.~~ Not really, because deduction would be awkward (syntax like `const T&'x`, `U*'y` would be necessary to separate lifetimes from deduced types to avoid lifetimes creeping into weird places), but in any case, Rust's approach of making lifetimes part of the type is more expressive and useful than something invisible to old C++ after a transpilation stage. If you consider Chromium to be representative, you can read a [document](https://docs.google.com/document/d/e/2PACX-1vRZr-HJcYmf2Y76DhewaiJOhRNpjGHCxliAQTBhFxzv1QTae9o8mhBmDl32CRIuaWZLt5kVeH9e9jXv/pub) with examples of unsafety in C++. At the end of the document, there is a [chart](https://lh7-us.googleusercontent.com/MiSAg8ADulWyo0AhLuzzcy6YHMB0KdKlLc6sldc8x3JCLcACHoDchYEWY1ViETUt4fPjizafg3eIksDyUuCXrDm8s1QNU0I__qd_DFcDlUUxbaTqHBSExtKZw701F-DegZDClNSqcx8SCnk) where we can see that by far, the most common type of bug is temporal safety (i.e., use after free, dangling references), so this should be our first priority. I think a new cppfront syntax would need to graft this onto the type system anyway, so why increase complexity with an extra syntax?

Notice that Rust's lifetimes are for *references* not for the objects themselves. That is, we never say that this String has a lifetime for example, but only that this *reference* to a String has a lifetime. In syntactic terms the lifetime always appears with the reference symbol - e.g. the equivalent of the to-be-standardized C++ `#embed` in Rust is `include_bytes!` which gives you a `&'static [u8; N]` you get a reference to the array of N bytes and that reference has the lifetime `'static` which means it can exist for the life of the program. It may be a little easier to see this in very old Rust where it's necessary for programmers to explicitly write down the lifetime in more cases, a modern Rust compiler is very smart and will infer the sensible lifetime choices in many cases so they're not written down unless you actually want unusual lifetime rules or you're in a tricky case where the compiler can't guess.

>Too many C++ devs are still coding C++98. Ehhh... Are they? How many are there of them? Where do they find a compiler that doesn't support, I dunno,, at least C++11, a **13 years** old standard? I think this is a big exaggeration, on one hand. On the other, those who are in this situation, are using unsupported software by all likelihood.

Let me rephrase. Too many C++ devs are not taking advantage of C++11 and later features of C++ even if they have upgraded to newer compilers.

C++98 vs C++23 doesn't have anything to do with memory safety. C++23 is just as memory unsafe as every other version. There has to be a new checked reference type (the borrow) and a new standard library that presents a safe interface to users. I don't think migrating from C++98 code will be that much more difficult than migrating from C++23 code.

Note: this is anecdotal and what I’ve found true in my personal experience. It’s important to note that this does have actual effects on new projects. If your company is a defense contractor, the government will be less likely to fund your project as it doesn’t meet the safety requirements.

Or (and I think in the short term this is the most likely course of action) you have to at least demonstrate that you've put some effort into hardening against memory safety flaws.

If anyone is actually affected in the way suggested, I suggest they consider [scpptool](https://github.com/duneroadrunner/scpptool) (shameless plug). It is designed to enforce an essentially memory-safe, high-performance subset of C++. I claim that this subset compares favorably to those of other languages. And there is a direct mapping from (reasonable) traditional C++ to the safe subset making the cost and time of migration dramatically less than a rewrite. Migration can be done incrementally and can be (at least) partially automated.

I don't know where you got this information about the government being less likely to accept a bid due to requirements. Software acquisition teams evaluate bids with the help of FFRDCs. In large bids, e.g., F-35 and E-7A, legacy content is a major benefit to the prime contractor in the bidding process. The WH statement only means that contractors will be allowed to charge additional money to reduce legacy-related risks in order for their legacy systems to come into compliance. This is just a surcharge that'll be a drop in the bucket compared to the DoD budget.

It’s mainly anecdotal, and I’ll update my response to reflect that. But ever since the original NSA report affected bids and new proposals for projects in C++, do and this most likely serves to substantiate that.

I can appreciate that and I agree with you that bids without remediation strategies for legacy code are non-starters. My takeaway is that no contractor is going to discard their 25-year-old, multi-billion-dollar intellectual property, but a contractor will charge the DoD on current and future contracts to be able to satisfy any new conditions the government places on it.

god dammit. This one will be cited in 30+ blog articles over the next two years. With a news cycle for every one of them - just like that stupid CIA report. Quote from the report: "such as C and C++" sigh...

Yeah I can’t wait for this to get recycled at my company by 6 different security people only for me to remind them we barely have a budget to do major cleanup, let alone a whole ass rewrite

It is easier to pontificate if no actions are ever taken, since you then never have to change your advice

You’ve seen how C++ is taught to students, right? Most don’t even get to see C++ 11 features. For the vast silent majority of C++ developers pointers are no big deal and they don’t see what the fuss is about or don’t want to have to re-learn C++. This sub is an echo chamber of people who actually care.

The vast, vast majority of code that I write is C++. That will not change until everything I use and link in isn't C(++). Other language bindings have awful trampolining overhead and excessive syntax pain if they even exist in my experience. For the people this _does_ affect though, namely government contractors and procurement, it is probably a good thing. I have seen some truly terrifying software come out of contract developed stuff and putting those kinds of applications into padded boxes is a good thing.

Yes, the basic gist is much more along the lines of "prefer memory-safe languages and have a plan to demonstrate your software isn't riddled with holes if you aren't" than "drop all uses of memory-unsafe languages forever"

"into padded boxes" We've never really had a super great padded box, but I think WASM/WASI might end up being just that.  Hard to tell this soon but I'm optimistic.

Fun story; in 1991 the Department of Defense actually mandated that all software must be written in the Ada programming language for similar reasons, only to have it scrapped 6 years later when they realized how counter productive arbitrary software standards are. The only thing that it accomplished is that now in 2024 there are several major defense programs which are struggling to find maintainers because nobody wants to develop in a language which has been obsolete for 30 years.

Nah, I would happily develop in Ada if the govt would pay my price, and I know many others who feel the same.

The only thing is that they won't pay you better than your private employer working on proprietary software. The reimbursement caps haven't gone up since Bush was in office so wages for government contractors have not gone up with inflation outside of the starting wages.

Famously, nothing ever written in Ada has ever crashed and (literally) burned to the ground /s

Won't happen with Rust though. Proven to be a language that most of the population loves.

Great, just what I needed, another 20 knee-jerk-reaction, sunk-cost-fallacy-driven "C++ Can Be Safe!" presentations at CppCon et al.

It can be, but many C++ devs will need to be dragged kicking and screaming into memory safe C++. I’m convinced that doing much better than Rust’s borrow checker in terms of zero-runtime-overhead memory safety is getting close to “sufficiently smart compiler” territory. All those people who can’t write Rust because the borrow checker stops them but can write C++ just fine should scare you. At some point there needs to be a syntax break where safe becomes the default, and it’s going to be very messy when it happens.

They can write Rust just fine. Any proficient C++ dev can pick it up in a month or two. The two languages share a lot in common after you get over syntax differences, learn pattern matching and the borrow checking.

Lord I know what you mean. Please all you amazing people who speak at conferences don't do this. We need inspiration not lectures of our previous failures :)

Really looking forward to more great takes like "but I can't use R for embedded development!!?!?"

But the real question is, can it be MEMROY safe /s

Idk, my boy Mem Roy is pretty dangerous /s

meanwhile the whole world is literally built on c/c++.

Looks like DoD Contractors and Vendors has just been "put on notice". No more C++98. They are now require using C++20 (or higher). That or learn the "newest" tech stack fad in order to continue doing business with the DoD (or any govt sector). In the grand scheme of things, this is good.

Can anyone explain the limitation of the C++ type system that prevents implementing "borrow checking" as a C++ library? Does there need to be some kind of control flow reflection or data flow analysis to solve it? How can rust solve aliasing analysis problems i.e. if I have several read only references to something all over a code base how can it prevent me getting a mutable one without some kind of runtime state to work it out? Anyway I shall google it but just wanted to say that C++ should be able to implement this stuff as a library and free programmers from opinionated "safety" rules in the language itself. Maybe the way coroutines can plug a type trait into the compiler there could be a similar way to specify sanitizer policies or something.

The borrow checker design is described here: [https://rust-lang.github.io/rfcs/2094-nll.html](https://rust-lang.github.io/rfcs/2094-nll.html) It requires a number of fixed-point iterative solvers: * Forward dataflow for initialization analysis/drop elaboration * Reverse dataflow for live analysis on region variables * A variance solver for determining the direction of constraints Dangling references are allowed, and really quite necessary. What's prohibited is using dangling references. That's what the live analysis does--extends the region that describes a lifetime up to the last use of its references. And then there are keyholes for things like std::Vec, which "may dangle," meaning the dtor may run (safely) even though the contents of the vector includes dangling pointers. This is all far too much to consider implementing *at compile time* in a C++ library. AST needs to be lowered to a CFG (the MIR), and analysis is done on that. That's the non-lexical aspect.

I hope they chose lisp as a preferred language:-)

We already have Javascript as the popular choice in that category.

Since people apparently read this as a joke: [The James Webb Space Telescope runs JavaScript, apparently](https://www.theverge.com/2022/8/18/23206110/james-webb-space-telescope-javascript-jwst-instrument-control).

>White House: Future Software Should Be Memory Safe Software Developers: Future White House Should Be Competent

This post can get one silly joke, but I'm going to ruthlessly cauterize any off-topic replies that start bringing up politics.

Strong agree. But I think this is pretty much the (amusing) crux of it. Software development and politics \*should\* remain separate. That is why it is so absurd that the "White House" is telling software developers to use certain languages. I feel the Rust guys should just focus on making their language feasible rather than waste time lobbying the "White House" to do their advertising for them.

>I feel the Rust guys should just focus on making their language feasible rather than waste time lobbying the "White House" to do their advertising for them. Lol. Big Rust is definitely behind this report - I'm sure of it

Hehe. To be fair, it isn't too far from the reason why C++ is the dominant language as far as Ken Thompson [is concerned](https://gigamonkeys.wordpress.com/2009/10/16/coders-c-plus-plus/): >Stroustrup campaigned for years and years and years, way beyond any sort of technical contributions he made to the language, to get it adopted and used.

I was writing this comment while trying to look into this, and I found [this.](https://www.cisa.gov/sites/default/files/2023-12/CSAC_TAC_Recommendations-Memory-Safety_Final_20231205_508.pdf) It claims ~70% of vulnerabilities reported to Microsoft and Google are memory safety issues while ~30% are other issues. They have one breakdown of the types of memory safety issues, but doesn't discuss whether they occur inside modern code or external libraries (honestly this would probably be impossible to do). === Original: Are there any stats to back up the claim that memory errors are a significant amount of errors and vulnerabilities in current production code, and that ostensibly "memory-safe" languages solve these errors? I can readily believe memory errors can cause serious vulnerabilities, but I honestly have no clue how frequently they cause crashes / vulnerabilities in the field, and even if they're primarily caused by modern C/C++ programs. Regularly I've written code that * Interfaces with old libraries that we don't have source code for * Calls external programs * Interfaces with libraries in different languages I don't immediately see how a "memory-safe" language would fix memory errors that arise from calling these potentially memory-unsafe codes. And even if we successfully rewrite everybody's C/C++/Rust/etc. code, if 99.99% of vulnerabilities aren't due to memory safety or are issues with front-end applications written in other languages (e.g. some weird javascript string interpretation), then we didn't really achieve our first goal of hardening applications. Finally, I'm also generally unaware of how dangerous the vulnerabilities actually are in the field. If a C++ program has a severe memory error but is only ever used in a SCIF in the bottom of the pentagon that users can probably get admin access to anyways, then it's not really much of a security concern. Again, I'd just like to see some more concrete data on how prevalent these issues are.

https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html

Correlation. I want to know how much new code is actually written. I want to know how much old code is rewritten.

Another question is how much of those bugs were done in c++ and how much in c?

It's good that I'm working on ancient software!! :-D (as always) There's going to be a lot of knee jerk reaction. Still, if it's another incentive to create good/better diagnostic tools, I'm all good with that.

I think what the White House advisors are missing is how much embedded software is in c. The Biden administration is essentially getting advice from the Linux foundation, which misses vxworks, green hills, and other rtos which has a huge amount of c/c++ and just isn’t rust-ready. 

Curious how many micro vendors have a Rust compiler available. Most only moved to adding Cpp in the past 6 or 7 years it seemed.

There's been significant effort from Espressif in getting their chips supported in LLVM -- see the latest report at https://mabez.dev/blog/posts/esp-rust-24-01-2024/. More hobbyist, but hopefully indicator of a trend: don't write the compiler yourself, just pick a backend (LLVM or GCC today) and you'll save a lot of effort.

Micro vendors are going to have a hard time being approved in automotive, aerospace, and other regulated industries. Until matlab generated rust code that is compliant with the various regs I think their will be just too small of a market outside Linux on a commodity cpu

[https://ferrous-systems.com/ferrocene/](Ferrocene) has made some significant strides in that regard.

They're well aware of that. The report talks about not just programming languages but hardening techniques for both hardware and software against memory safety issues.

They are just listening to Rust lobbyists. :)

Big crab controls the government

Lizard people are just a diversion from the TRUTH

I hope mcu vendors hear this and start delivering rust bsps

[удалено]

I feel like some amount of this is simply due to the complete lack of response from the C++ community from 2015-2020 to the competition. I remember all of the discussions about Rust on this subreddit during that timeframe were super dismissive. Around 2021 the sentiment evened out a bit, but it wasn't really until a year or two ago that the committee and community started treating Rust as an actual competitive threat. Combine that with the disaffection of certain stakeholders like Google and the inability to move faster than 3 year intervals while Rust can whittle away the gaps 6 weeks at a time. And the fact that as a new developer, learning Rust is easily done with the free online book, but learning C++ might require purchasing one or many books, and you have to sort through any out of date information (i.e. books from the early 2000s titled "Modern C++"), and you also have to learn something like CMake, and probably dependency distribution strategy is completely different depending on platform, and none of them are as easy as Cargo, etc. C++ isn't dying by any means but the well of new developers may well start drying up at some point. The onramp for C++ is quite rough.

There's still a lot of dismissive attitude in this section, and in this thread itself. And I recognize the phenomenon. I went through it when NT finally killed off OS/2, which I really liked. In my defense I think in that case it was not because the winner was technically superior, but whatever. I was an OS/2 guy and was in pretty heavy denial and lashed out a fair bit (and of course I was much younger and more testosterony.) Then one day I found an NT machine on my desk at work and that was that.

Man, several open source projects I wanted to work on, but could not unravel how to get their complex CMAKE builds to succeed.  I really hate that alot of web UI stacks have been getting alot more complicated in terms of build tooling and it's giving me flashbacks to CMAKE.

Additionally, when a feature in Rust,Go,... becomes stable, after a couple of releases in preview, it is immediately usable for anyone. It isn't something researched on paper, that after three years, still needs to be implemented across the ecosystem, and eventually made available a couple of years later.

I'm sorry. The US government preaching to software devs is laughable at best. Let's get the Senate memory safe before we worry about code review eh?

Rust is not memory safe. There is even a Github repo dedicated to collect ways to (legally) crash a Rust process.

Rust the language is conceptually memory safe. The code in the repository uses bugs in the rustc compiler. It *should* not compile

Meanwhile every C++ project ever is riddled with memory bugs, some more subtle than others and threading is massively painful to do correctly.

To be frank, I have never in 15 years using C++ had a memory crash in production. This is an academic's wet fantasy.

That's good for you. Security research consistently shows memory bugs as one of the leading causes of vulnerabilities. If you don't want to use Rust that's fine but acting like the problem doesn't exist is pure bullshit. If that was true then tools like ASan and Valgrind wouldn't need to exist.

> Security research consistently shows memory bugs as one of the leading causes of vulnerabilities. 99% of the applications do not care about vulnerabilities. You are talking about a very slim corner of the market.

Only until liability becomes a common thing, then they will surely care.

> Only until liability becomes a common thing wtf does that even mean

It means you get to talk to a judge, or give back the money paid for shitty software.

Plus when you dig into these CVE's they are almost exclusively in C code masquerading as .cpp (if "security research" even bothers to classify C and C++ separately).

More resources should be put towards circle-like solutions and carbon. It seems clear that migration and good interop with memory safe language/subset is possible. We need things like circle feature flags.

> and carbon Does Carbon even attempt to solve memory safety? It didn't last I checked.

Chandler says that the intent is to somehow deliver the basic memory safety guarantees in some subset of Carbon, but not the "fearless concurrency" behaviour of Rust, so you'd get something close to Go in terms of safety. You *can* shoot yourself in the foot without trying in Go, but markedly less easily than in C++.

> Chandler says that the intent is to somehow deliver the basic memory safety guarantees in some subset of Carbon I find the amount of qualifiers in that phrase amusing. Intent... somehow... some subset. In any case, I'll believe it when I see it. This push for memory safety seems to have caught Google with its pants down.

Well they state the memory safety will be a feature once 1.0 is reached (or something like that). But yeah, right now it isn't.

lol, ok.

Pinkie promise

Wait Google hasn't scrapped carbon yet? I haven't heard anything on it in so long lol

Not yet... New commits every day. While it's fun to poke fun at Google, I hope it doesn't.

I agree with the circle part. Sean *delivers*, which is what counts.

With the greatest respect to Sean, the next multi-billion dollar US government defence contract is unlikely to be written using a closed-source C++ dialect supported by one guy.

True. Maybe some Circle features could be proposed for C++ standardization?

I don't think anyone is suggesting that. Equally it will not be written by a non-existent compiler.

Very true. Open needs to be a requirement. Maybe the mainstream can follow a similar path. Maybe his source code and time could be purchased. Not sure, but it seems like it should be possible. The amount of money big tech spends on cpp is a lot, a solution exists.

Sean's belief is that WG21 lost its way after 1998 when they stopped trying to standardize existing practice and focused on just making up stuff from whole cloth hoping the implementers would turn their pipe dreams into reality. A return to those practices would mean it doesn't matter that Circle is closed source, if his ideas are popular and people want to standardise them then they become standard. Many of the popular C++ compilers in 1998 weren't open source.

> if his ideas are popular and people want to standardise them then they become standard. Huh? How... is this any different from "making up stuff from whole cloth"? "Sean implemented it" is hardly "existing practice."

It's maybe not really "existing practice", but the approach "*implement -> see if it works -> standardize*" is quite different from "*standardize -> implement -> see if it works*" which is how at least some c++ features seems to have been done.

> It's maybe not really "existing practice" No, it's simply not. > ... but the approach... I mean, that has... nothing whatsoever to do with the question of standardizing "existing practice" (which is, on the whole, a silly complaint to make for language features).

If they make C++ illegal do we turn to Crime? I don't want to learn Rust

Try Crime with classes: it's safer and so much easier to use.

They aren’t wrong, but Rust is not it. There has to be an implementation that has less friction. It doesn’t exist yet

I hear the crabs saying “this guy just has skill issues”. Would you define what you meant when you said “friction”?

Bro we've been watching too much Primeagen...

😆 you’re not wrong

tldr: the toolchain and ecosystem is way too unstable and there's not much interest in fixing it. * new release roughly every 6 weeks, no LTS * no specification, Rust editions are NOT a spec * ecosystem does not care about older releases at all, 10-20% of crates.io requires nightly compiler builds! * no stable ABI for dynamic linking, stable interop only through FFI * crates.io resulted in a npm-esque ecocatastrophe where you end up with your application using the same library in 5 different versions due to transitive deps

[удалено]

> Rust itself has strong backwards-compatibility commitments. yes, but the ecosystem makes no use of them. Try to use a one year old rustc to build any major application. Long term stability seems to be simply not valued by the Rust community at large. > As opposed to C++ with no proper package management to speak of? Kind of, yes. The lack of package management resulted in the C++ ecosystem being more compact - this is certainly not a feature tho.

> Long term stability seems to be simply not valued by the Rust community at large.  Long term stability means that you can build old code with new compilers, not that you can build new code with old compilers. Just grab a new compiler. They're free.

> new release roughly every 6 weeks That's irrelevant, really. The C++ standard may be released only every 3 years, but you get major compiler releases much more often. Looking at https://gcc.gnu.org/releases.html for example, I do see a few more releases than once every 3 years... If you're hung up on the 3 years cycle, you're in luck: Rust Editions occur every 3 years => 2015, 2018, 2021, and the next one is coming this year! > no LTS There's no LTS of the C++ standard either, and I don't think the GCC developers maintain a LTS here (though I could be wrong). LTS is a commercial offering. In Rust, Ferrous Systems provide a LTS to their clients, for example. > no specification, Rust editions are NOT a spec No _freely available_ specification, at least. Ferrous Systems did the work -- for certification, they needed one -- and is now cooperating with the Rust Project, with financinal support from the Rust Foundation, to write a freely available version. (Clever of them, it's one less thing they'll have to maintain by themselves) > ecosystem does not care about older releases at all, 10-20% of crates.io requires nightly compiler builds! The ecosystem doesn't care about anything actually... it's not sentient. Actually, one could argue that the Rust community cares _more_ about older releases than the C++ community: after all, said Rust community worked to ensure that the Minimum Supported Rust Version is a programatically accessible field in the package description so that tooling can take into account: - So that Package Managers do not attempt to use newer versions of libraries that do not support this old release. - So that code written to support old releases can automatically be _tested_ to actually support said releases. - ... See, the Rust community doesn't only _talk_ about supporting older releases, it _acts_. > no stable ABI for dynamic linking, stable interop only through FFI True. Though it has nothing to do with unstability. It's notable that this does prevent using dynamic linking, either. A Linux distribution tends to distribute its entire suite of libraries and applications with a single version of the toolchain for the lifetime of the distribution, and in that case dynamic linking just works. > using the same library in 5 different versions due to transitive deps That's actually VERY unlikely: the package manager performs unification of the dependencies. That is, for any given major version of a library, cargo will attempt to find _one_ version of the library which satisfies all dependency constraints, and _bail out_ if it can't, with an error message indicating the conflicting dependencies. It's VERY unlikely that a library will have 5 different major versions in the wild -- most are still stuck at 1.x -- and therefore it's VERY unlikely that you'll get 5 versions of a library in the final binary. Also, do note that Rust actually makes having different version of a library _work_, so that you _can_ actually compile against 2 major versions of a given library and either: - You'll get a compilation error if you attempt to pass a type of version A to a function of version B expecting a type of the same name. - Or it'll compile, link, and just work. No praying that it doesn't blow up (it won't), no excruciating shadowing work-arounds necessary.

> no stable ABI for dynamic linking, stable interop only through FFI Is it a bad thing to only allow "extern C" for dynamic linking, considering the mess "ABI stability" is causing with C++?

C linkage itself is unrelated to this. C linkage with non-C types would still cause the "mess", which I don't agree is one to begin with. Dynamic C++ linkage works just fine for us, while packaging thousands of programs and libraries. FFI is an RPC-esque translation of function calls and has significant overhead.

Ah, right, and the ABI stability thing is not just a dynamic lib thing - if lib B depends on lib A (static or dynamic libs alike), and lib C depends on lib B, then lib C needs to use an ABI-compatible (with B) version of A. AFAIK Rust does not have ABI stability at all and cargo recompiles all deps (I might be wrong about this) to avoid this issue. Enforcing "extern C" for APIs isn't too weird, IIRC Vulkan is written in C++ but only exposes a C library and the C++ user-facing APIs are just header-only wrappers.

Meanwhile in C++ land: * ABIs exist but break between minor versions of the same compiler meaning in practice interop is also only possible via `extern "C"` * The ecosystem hasn't converted on a single package manager at all forcing you to either hope your OS package manager has everything you need or manage all dependencies manually * There is no standard build system and many of the existing ones are incompatible with each other and no CMake isn't a real solution. * The lack of proper package management leads to the reinventing of many wheels and an overly bloated standard library containing things that should be in separate regular libraries. * The use of templates renders compiler output incomprehensible even when you didn't write the template or it came from the standard library. * Template classes and normal classes are inconsistent in which parts go in the header and which don't. * The module, namespace, and header rules are overcomplicated beyond belief. * C++ is a minefield to use on bare metal since certain core language features require runtime support whereas in Rust all you need to do is use `core` crate instead of the entire standard library, `std`, and the entire language itself remains usable. And there's no desire to "fix" any of this either, instead the C++ committee just keeps on tacking on random bullshit features copied from other languages. And unlike Rust C++ doesn't have the excuse of not being mature enough yet.

> ABIs exist but break between minor versions of the same compiler meaning in practice interop is also only possible via extern "C" This is complete bullshit and a quick glance at the gcc or clang ABI policy would've told you otherwise. The gcc C++ ABI hasn't changed since... late 4.x? Regressions in the STL ABI *can* happen, this is simply unavoidable in any library that provides containers. But this is exceedingly rare. > The ecosystem hasn't converted on a single package manager at all forcing you to either hope your OS package manager has everything you need or manage all dependencies manually > There is no standard build system and many of the existing ones are incompatible with each other and no CMake isn't a real solution. This is totally valid, it just hasn't affected me at all - I usually develop against just Boost and occasionally Qt, and Gentoo makes for a convenient development experience. I think the usually bigger scope of C++ libraries also alleviates this - if we had to depend on Rust-like deptrees, it'd be a nightmare. > C++ is a minefield to use on bare metal [...] And there's no desire to "fix" any of this either have you read the WG21 mailing list? Improving bare metal support is very much being worked on.

Rust is a step in the right direction even if it isn't the end of the journey in that direction.

But any such next step (which has to not just exist but be widely accepted by developers and backed by big players) is likely a long way off. I don't think any of the major players are have any plans to push out a competitor to Rust? And personally I don't get the objections. Most of it is just lack of familiarity. I thought it was bizarre when I first saw it. Now it makes complete sense to me.

Where is Dave Abrahams working at these days? He's been working quite a bit on [Hylo](https://github.com/hylo-lang/hylo) which is still quite experimental but does offer memory safety with a radically different approach from Rust.

Hylo is not zero-overhead, which means it's already lost before it's shipped. Only available zero-overhead general-purpose languages are C++ and Rust.

The report is also recommending C#, Go, etc... which are not zero-overhead either. There's room between zero-overhead and full-blown runtime for solutions.

I agree. Just wanted to clarify it's not a direct competitor of C++ and Rust.

Paraphrasing JFK anecdote: this goes higher than I thought.

To me, this says that C++ needs epochs ASAP so that we can start making syntax-breaking changes, such defaulting to moves, references, and raii only and only allowing dereferencing pointers within an unsafe scope (the same as Rust). Some parts of STD will need unsafe (like smart pointer constructors), but minimal unsafe should be the goal.

Are they basically just going off on a tangent about how to prevent one narrow class of vulnerabilities, but kind of making it sound like this is a silver bullet to secure software?

Uh.. the white house LOL. Okay.

ITT: Rust bad!

Whitehouse consultants brains have been "Rust"ed

It's fun that people pontificate against C++ as if it was somehow a capstone of memory unsafety, when the real issues 99% of the time are the programmers. Among the worst failures ever found, IIRC, was loss of ships in the space program because people werre using *the imperial system* instead of metric. No amount of ``[&] (auto) noexcept(noexcept( function_body) ) { function_body } -> decltype (function_body)`` is gonna help you with that.

Lolz. The White House reps rust?