Discussed recently:
Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk (01.11.2024)
If the USG wants this then they need to start inserting it into Statements of Work then companies bidding on this type of work can assess impacts and provide a business case. It will be slow but start there. The same way Risk Management Framework works, DoD 8570, etc
They will. This language is already creeping into contract discussions, though nothing I've been party to has actually required dropping C or C++. It's making it into RFIs already. It'll be in actual requirements in a couple more years, probably. And then it'll be forgotten like Ada before it.
C and C++ folks like to play Ada card, missing the fact that it didn't took off due to the price of compilers and the hardware to run them, coupled by cheaper C and C++ developer salaries.
They miss the fact we aren't in 1980's any longer, Infosec and pentesting is standard procedure before deployment in many industries, insurances and companies now have a ball in the game regarding cibersecurity and nation state sponsored attacks.
RFIs are great but if it’s not in the SOW then it’s a desirement and the contractor is correct to reject. RFI all they want - put it in the SOW and turn it into a requirement.
There are lots of big government contractors (Raytheon, etc) still writing and maintaining a lot of Ada.
Agree. Those companies was what I was referring to
Linus does not use standard C either. Linux kernel depends on -fwrapv switch (reduced UB on signed ints). Also in discussion about Rust mentioned the kernel has lots of infrastructure that almost makes C into different language.
Couldn't one pre process all of these unsafe c things with additional overflow checks and just crash. Let the cpu branch thingy do the optimizations
So all we’d have to do is convince C programmers to use a slightly slower libsafec because it’s demonstrably true that no one can use the current language safely? Seems easy enough!
But really, no, one could, but one won’t. It’d be easier to convince everyone to switch to Rust than to a safer C.
Safety in C improves dramatically with good tooling and coding practice and you can slowly move to safer C without much pain. People who really do not care will also create problems with Rust.
We've discussed this before. The issue is the same that it's always been. A single mistake anywhere in your codebase means that all language invariants are no longer upheld. No tooling can statically guarantee defined behavior, only catch some of the easier cases. I work in a codebase where we do all of that high powered static analysis and I still regularly find issues with simple tools like ubsan (which isn't remotely exhaustive).
Any instance of undefined behavior in safe rust is a language or compiler bug. The only things you really need to check are unsafe blocks, which are rare enough to individually review line by line on a regular basis.
I see Rust code with quite a lof of unsafe and sometimes it has bugs, sometimes triggered from preconditions broken outside of the unsafe block. So no, I think it is an oversimplification to pretend that "only a couple of lines need to be reviewed". And then there other safety issues than memory safety.
But I think a safe C that has similar guarantees as Rust is quite possible and we can gradually move there.
I only mentioned undefined behavior. Memory safety is a subset of those issues, but rust's actual promise is eliminating all UB in safe code.
In almost all cases for preconditions, that's solvable by better practices that could be identified in a review. It's the same underlying problem as C, but dramatically more manageable.
And of course, any C is liable to be misused in C++ where the committee's current position is that the problem is unsolvable.
It is the same problem in C and more manageable. I just doubt the "dramatically". And C problems also become more manageable with better tools and more focus on safety in the language evolution.
I completely agree that C and C++ become more manageable with modern tooling. The problem is that better doesn't fundamentally change the situation. How UB is defined in the standards means semantics are an all or nothing situation. Either there's no UB and you have the semantics specified by the standard, or you have UB and no semantics (past the point of UB in C23 thanks to your proposal). We've had a solid 30 years of history demonstrating that exhaustive static detection is impossible and every nontrivial program has UB of some kind.
You can't fix this with minor changes in the language or improved tooling. You need a complete overhaul of how the standards and implementations deal with UB.
But Rust shows that static detection is possible if you add constraints to the language, and this is exactly what one can do it C too. Rust was inspired by a C dialect after all. The situation with UB is not actually as bad as it sounds (I analyzed all UB in the core language).
Ignoring memory safety where rust's solution is more obvious, the lack of UB in Rust is mainly the result of consciously deciding to eliminate it. Signed overflow is implementation defined for example. The parsing UB that takes up half of annex J is eliminated by simply expecting that implementations write proper parsers and having a better macro system. Invalid enum values were solved by a stronger type system.
If there were actually an appetite to eliminate it, I suspect we could probably eliminate 70% of J.2 with a few straightforward changes. Many of these aren't completely amenable to static analysis, like signed/shift bounds, but they're workable at the language level. The members of the C++ committee I've talked to were skeptical about the actual chances here though.
The rest of annex J is at least partially addressed with existing efforts like checked C and Coral ("constraints"), so at least there's a path forward with tooling.
The things you mention are already ongoing. We eliminated 15 items in J.2 in last meeting and will remove more in the next. Not that I agree that the UB is really the that much of a problem, only very specific cases of UB actually cause real safety problems.
In my domain (safety critical), I'm interested in taking a piece of code I didn't necessarily write and making statements about the state of the system at various points in the execution. It doesn't matter whether the UB that exists doesn't result in observable misbehavior of the system as it exists today, I also need to ensure that the system will continue behaving in 10-50 years with a different compiler on a different architecture that may not even be designed yet.
Currently, all of that work has to come with a little asterisk saying "except for undefined behavior". I can't constrain where UB might be in the system, or how it might violate the safety model. In short, if I do my job properly I shouldn't assume C/C++ semantics at all. Obviously that's not reasonable, so everyone goes around pretending this isn't an issue to their safety models and their regulatory filings and so on.
Obviously I think that's wrong, but there haven't been ways to address it in C and C++. It's possible in Rust.
The thing with UB in C is that it was traditionally seen also as a possible extensions point, so someone else can come in and define the behavior, e.g. POSIX does it for some. But yes, we understood that this is not how people look at this anymore, and hence we will remove it.
But I do not see how Rust helps? Rust has no standard and its reference implementation is subject to change. How did you convince yourself that what ISO C leaves not-standardized is any worse than what is not being standardized in the first place? There seems to be a double-standard here.
The comparison isn't with rust today, but the long term differences between the languages. Rust has a straightforward path to rectifying the standardization issue and enough community momentum to succeed.
For example, Rust has an in-progress specification, here's the (currently empty) repo: https://github.com/rust-lang/spec. There's also MIR, a de-sugared internal representation that's sufficiently well specified to build formal models of (see https://github.com/rust-lang/a-mir-formality and https://github.com/rust-lang/miri), as well as the ferrocene spec (https://spec.ferrocene.dev/general.html) that's suitable for certification authorities (if not actually useful) and of course the rust reference/RFCs that are actually usable by people.
Plus, the fact that everyone in the rust community has standardized on one compiler and one package manager (for better or worse) means that the language team has a much better insight into specification breakages than the ISO process of languages like C and C++.
I can start writing stuff today and be confident that any changes will be minor if necessary when the language catches up.
I'm more than happy to have this discussion over email if you want to move it off HN, too.
You can always wrap C into a higher level language that makes it safe, but why the hassle? That new language might as well be Rust,which is built up from the bottem with safety in mind.
Rust has quite a few problems which why I would not want to use it for my projects: High complexity, long compile times, not stable, not standard, supply chain issues, etc.
I genuinely don’t think we can move there at all. There are significant cultural issues: as soon as a safe version with bounds checking is 2% slower, a significant chunk of programmers will claim they can’t use it. There’s also the glacial pace of tooling changes, so even if a safer C existed today, it’d be a couple decades before it was commonly used.
But frankly, if you’re going through all that trouble, it’s probably worth considering a newer language that fixes those things today. I mentioned Rust as one example, not the end-all solution to all problems. Nim also plays on the same space and it’s quite nice. The broader point is that I believe it’d be easier to start writing new code in a different language that can easily call existing C code.
I do not think newer languages are the solution for two reasons:
First, all those new languages also have various downsides, and trade-offs, which may make them a less than ideal choice for many applications. Second, there are an incredible amount of existing C code. We will not get rid of C in the next at least 50 years even if we wanted to (not that I want to). Incrementally improving that code is far more useful than adding other languages into the mix.
And yet we can also just look at how memory vulnerabilities have impacted the Linux kernel over the years in order to assess how much they have helped to reduce the risk that memory unsafe languages bring.
You're right, and it's not just memory safety in the use-after-free sense. I just had to audit some out-of-bounds read CVEs, like https://nvd.nist.gov/vuln/detail/CVE-2024-46723. Rust really makes you work hard to read past the end of an array.
Rust makes a lot of things hard.
Update: From your CVE "Clear warning that read ucode[] may out-of-bounds." So it seems this was catched by tooling.
…after public release. It’s nicer when tooling catches problems before it successfully compiles.
Not if this means horrible long compilation times. I agree it should be catched before a release. But this is a question of procedures and not of programming language.
Rust should just build their own super safe OS, instead of nagging existing projects to adopt their practices. If they can successfully build an another successful OS it is much more convincing.
What makes an OS “successful”? Does that have anything at all to do with the point they are making?
Do you just mean, successfully make an OS? Because there are multiple examples of Rust based operating systems that are complete or nearly so.
Or by “successful”, do we mean that it is popular? Because popularity has rarely correlated with technical superiority in the past ( or present ). Windows is much more popular than Linux. Linux surged to popularity when FreeBSD was more complete and technically superior. Plan 9 has entered the chat.
Popularity depends on totally different skills and circumstances than technical excellence. Memory safety, performance, and security do not necessarily drive popularity.
What do we mean by success?
> What do we mean by success?
They should write an OS that is "so good" that people start talking about it as much as the options we have now, then people actually start using it on their servers (replacing GNU/Linux), then on their desktops. So good that companies like Google and Apple would consider making their next OSs or userland utilities in Rust.
It already happened for some programs like Alacritty, ripgrep but failed to do so in some other domains like user-space window managers.
The common argument against it is complexity and learning curve (compared to C).
Perhaps I'm not the one who should voice his opinion on this but anyway, I don't like _two_ languages in Linux kernel especially one that increases compile time and imposes heavy storage requirement on the development machine. If they want to add it, they should consider migrating everything to it IMO.
> They should write an OS that is "so good" that people start talking about it as much as the options we have now, then people actually start using it
Is the proposal here to replicate the 30 million lines of code of Linux? Anything short of that is going to have massive adoption problems, much like Linux did in the past, much like FreeBSD/Illumos/etc do now, due to the lack of drivers. It took so long, and devices still don't properly support Linux; there is no way another free and open source system will take off like Linux did, ever again.
> failed to do so in some other domains like user-space window managers
Do things like Way Cooler and COSMIC not count?
I have seen Way Cooler mentioned as being used a couple times, and COSMIC gets regular coverage for its development progress.
exposing billions of people to security vulnerabilities by preventing Rust from being used in Rust due to compile times or storage requirements of developers is morally questionable
> Linux surged to popularity when FreeBSD was more complete and technically superior.
Is that true? Is there somewhere to read up on that? Why Linux became more popular than FreeBSD especially?
BSD already was a complete operating system by the time linux kernel development started. unfortunately in 1992 there was a lawsuit that put the license of the BSD code into question. by the time the lawsuit ended and the license was clarified or confirmed, linux+GNU had already taken over in popularity.
Put your money where your mouth is govt! Make memory safety a contract requirement.
They won't. If they did, things would become more expensive, and they would take longer. So they won't.
Well this is all just pretty platitudes then. You get what you pay for.
Shame because I'm not opposed to a shift to Rust tools for safety's sake.
1991 Edition
https://www.gao.gov/products/imtec-91-70br
Pursuant to a congressional request, GAO obtained information on the Department of Defense's (DOD) implementation of legislation which mandated using the Ada programming language for all software development, where cost-effective.Folks that play the Ada card miss why Ada didn't took off in 1991's hardware.
Didn’t the Department of Defense try to mandate Ada in the 1980s? That went nowhere.
Ada 95 is still around. I know personally and have used it. It is being slowly ripped out of a major system but it persists. AdaCore and GNAT help a lot too.
It went to 7 Ada vendors still in business in 2024, in an age where many folks refuse to pay for their work tools.
Folks that play the Ada card don't get then issues regarding compiler prices for Ada, versus C and C++ free UNIX compilers (it was an additional license on UNIX SDKs), the hardware requirements, the salaries for devs with Ada skills, and yet those 7 companies manage to stay in business.
You mind your own projects, I code in what I like.
> If only it were that easy to snap your fingers and magically transform your code base from C to Rust. Spoiler alert: It's not.
This misses the point. The point is to start moving in that direction, not instantaneously.
Sounds idiotic if you ask me.
What's really needed is an official Engineering qualification for programmers, like you leaglly have to have if you're an Electrician or Gas Engineer, etc. Liability Insurance in case of damaging bugs.
Literally anyone can call themselves a Software Engineer, which one the one hand is great because it's accessible, but also a curse in terms of making it a respected profession.
People don't care about "respect" if they getting a 250k salary for it. For that level of salary people will flock to sanitation services in a heart beat (aka pickup trash and dog through dumps for a living).
I kinda sorta agree with you, but I see two immediate issues
1. There's such a variety of domains in software. And even in a domain you're always finding odd, unique problems that no test prepares you for. There's too many skills each domain needs to boil down to one universal test
2. The main reason I'd love a license is to cut down on interview gauntlets. But I'm too cynical to believe we still won't just end up with 4-7 stages of something else. Or even the exact same damm thing. What's the point of a license if no one trusts it over their cruddy beauracracy they call an "interview"?
If you design a bridge that collapses in a way that could be anticipated, you screwed up. Software can fail in ways no one's thought of yet, as evidenced by us still finding new classes of bugs. And even when you write perfect software, it's impossible to know that it's going to evaluate correctly when built with an arbitrary compiler on an arbitrary OS running on an arbitrary hardware platform. Something perfectly fine on Clang/macOS/ARM might be busted on GCC/Linux/x86.
Engineers have to be responsible for their work. If you held software engineers to that same legal standard, the occupation would be sued out of existence within a year, even for people who are doing everything possible to do it right.
As a devil's advocate: engineers are so often told to not do things the right way (skip tests, go faster, implement ethically questionable code, etc) that a license can give an engineer some weight.
Of course if they ignore a licensed engineer, they'd have their version of "Against medical advice" to sign off that liability to the company. Sure, there's still be unknown unknowns that come up and screw over the engineer, but I imagine a lot of the lawsuits would be redirected to the companies that prioritized shipping any kind of slop over all these engineering principles.
If you are a licensed engineer that happens to be doing software, you can probably play that card.
Those people would be the first casualties, because they would be working where the stakes are high.
No. This is often stated, but I believe provable systems make far more sense than provable people. Exclusionary qualifications and gatekeeping are an anachronism that needs to die. It's a positive thing that computing has lead the way in this area. Other facets of engineering need to do the same.
It's impossible to even aim for provable systems when the dominant paradigm is moving fast.
Would you let someone - whose only qualifications is watching YT videos and tinkering around their own home - wire up your house and install your gas appliances? Would your insurer accept that?
That's equivalent to asking if I would let a hobbyist programmer who just learned python to write his first computer game design and implement my production system.
A better comparison would be "would I let someone who self-learned wiring up houses, and then spent five years working under an expert, before finally branching on his own, wire up my house". And the answer is yes.
IMHO, the actual barrier to entry to writing software is so low that trying to raise artificial barriers is unlikely to be succesful.
Especially in a world where disclaiming liability is the norm on all sorts of agreements, why should general software be different?
Software related to life safety tends to have real liability attached.
why? i don't think it's any different from requiring a degree. if a qualification exists it most likely can be tied into a degree. like in law for example. you study law and then you pass the bar exam. seems pretty straight forward
In case of software development, plain old common sense tends to take you a lot further than some certification. It is more easy to spot the professional fault leading to a gas leak than catching the professional fault of creating software resulting in subtle race conditions.
It's not just spotting leaks, you can't even install gas applicances without a professional qualification even though most of it is common sense. Yet, literally anyone can work on any type of software without having any sort of proof they're competent in that area. It's all hope and trust.
I expressed myself unclearly.
The gas cerified person gets repercussions because someone found leaks in the pipe fittings this certified person made. The leak is a smoking gun.
OTOH The software dev, certified or not, will not get repercussions because of their racey constructs, since it is much harder to point out they did not follow some certified procedure other than some (non airtight) tests and reviews before release. There's no smoking gun pointing to uncertified way-of-work. There's only this one in a million happenstance of a race condition making the system fail. That's where the common sense comes in, only that will prevent/solve possible race condition. There simply is no certified way about it like in pipe fitting.