Google's memory safety plan includes rehab for unsafe languages Google has revealed that its approach to making programming code more memory safe involves both the adoption of memory safe languages and making unsafe languages more secure – to the extent that's possible. The Chocolate Factory has been an avid booster of memory safety for the past few years – celebrating the security …
So why were they allowed to use C strings in the first place? No code review caught that out? That could even be automated by getting svn and git to refuse commits which contain "char *".
Back to Google, did management enforce use of RAII, ban use of known unsafe language features, allow time for refactoring old code to use newer C++ features, and improve the toolchain? I suspect they didn't because they admitted as much ("Given the amount of C++ code we use, we anticipate a residual amount of mature and stable memory-unsafe code will remain for the foreseeable future"). If they chose not to follow best practices then decide that's a reason for Rusting all the things, they're going to be surprised when they find there are still problems in their Rust code but I won't be as no technical solution on Earth will fix their problem - they have a management and cultural problem.
Manglement anywhere aren't exactly noted for their technical excellence, or even competence - technical or otherwise.
Suggesting to google management that enforcing the use of RAII might only elicit uniform vacant looks with perhaps the unlikely but definitely odd genius wondering how using a papyrus boat might help.
That's what tech leads are for, to say why it has to be done to management (that's probably what went wrong in Google...).
If you're wondering why management keep buying into stuff like cloud, AI, and the new language du jour it's because sales got there first.
" So why were they allowed to use C strings in the first place? No code review caught that out? That could even be automated by getting svn and git to refuse commits which contain "char *". "
Good luck interfacing with an operating system (or many, many widely used third-party libraries) without using char*.
I mean, yes, one can in principle write some kind of safety layer, but to do so for a sufficient number of them to be useful would be a Herculean task. (There is a reason that most languages offer a way of binding to C-linkage APIs.) It might be quite a *useful* Herculean task. A complete (or even >50% complete) interface to Linux or Windows that was safe C++ would be a very useful thing. Many people would thank you and start using it immediately. Some of those would probably even join in and help you finish the job and maintain it as the OS evolved. But I don't see any evidence that such a thing has even been started yet, despite its utility. Perhaps it is just too scary to contemplate, or perhaps people reckon that writing an OS in a safe language is going to be easier.
"No code review caught that out?"
I didn't say it made it to production, at least not all the time. But, often the code reviewer is more clueless than the original developer. Unless you want your one or two semi-competent developers swamped with a tsunami of shit to review. We still have a business to run and sometimes it has to run on crap code.
The point I was originally trying to make is that the vast majority of developers fail to grok the importance of using an appropriate type to represent the things that occur in the problem domain. Usually this will need to be a user defined type aka a class that has the right properties and behaviour for the domain entity it models. That's the great thing about C++, you can define types and operations on them and they look pretty much like they are built-in and if well designed will pretty much look after themselves and the resources they own. You just need to understand the domain and the language which appears to be a rare combination.
Throw in some lifetime management idioms like RAII, smart pointers, factories etc. and it ought to be really hard to screw up. And yet... Oh, but performance, oh but I'm special...
C++ in the right hands is significantly less "unsafe" than C, but still we keep seeing references to C/C++ as if the risks are the same. Please stop conflating them.
I believe the argument that a lot of folks make is that if the programming language lets you do X, then programmers will do X. With languages with a lot of implicit operations (which I personally think C++ is), it can be difficult for even a good reviewer to spot all uses of X. So, if X is a bad thing, there will be bad things in a lot of code.
Hence the attractiveness, to many, of an entirely new language. It doesn't let you do X. Or if it does, it requires special syntax to enable its use, and warns about each and every such occurrence. The former is safer, since developers can wrap the compiler and filter out warnings.
Using a new language also has the benefit (and cost, of course) of forcing a rewrite of code. As most progammers know, rewriting code, even in the same programming language, often produces good improvement, and often bug fixes.
I am *not* a C++ guru, so I'll ask: would it be at all possible to modify compiler sources to produce such an alternate language?
(I've always started my languages/compilers from scratch, so have no experience in hacking existing compilers.)
Ah, "the great rewrite in the sky", to paraphrase Uncle Bob. I'm sure it'll be better for some definition of better. But how long can your organisation stand still whilst you do that? It'll take way longer than you think even using the tools you are already proficient with never mind learning a whole new set as you go along.
I much prefer to refactor. Rewriting from the inside out a little bit at a time. But success at that relies on lots of things, like decent test coverage. And you will find brokenness along the way. I once pointed this out to a business sponsor who insisted he was the only one qualified to open new tickets. Apparently he preferred to hear about defects from angry customers rather than his own colleagues...
Yes, overly liberal conversions can be a problem in C++. The standard caught up with that eventually and now you can flag conversion operators as explicit which limits the contexts in which they can be used to (mostly?) harmless ones. As usual its opt-in, not a default, to remain backwards compatible.
This quote was on USENET over 20 years ago. I saved it because it's such a concise statement of the problem.
"After 30 years, it should be pretty bloody obvious to everyone (but apparently the memo has missed a few people) that all but the very best C programmers are nothing but a danger to themselves and others. Pointers, arrays without bounds-checking, uninitialized variables, and manual memory management are an endless source of bugs and security holes, and most people should not be trusted with them on a regular basis."
-- Mark "Kamikaze" Hughes
"Pointers, arrays without bounds-checking, uninitialized variables"
Now that we have oodles of memory and processor power, is it not possible to create a "safe C" that will compile C code and include stuff like array bounds checking, faulting pointers that have not been assigned a non-null value (and forcing it to null when it is freed), and so on? That won't catch all the C quirks (like pointers to pointers to functions) but it should deal with a lot of "failure to bounds check" and "off by one" cockups.
Take a look at Zig - it’s the closest I’ve seen yet to a “safe(r) C”. I’ve been looking at it over the last couple of months (check out the tutorials by “Dude The Builder” on YT) and I think it’s got legs. It’s got a lot of really nice features, but retains the simplicity of C. I really hope it catches on
You get my vote!!
I love C. It’s such a wonderfully simple language. If you don’t have the discipline to use it correctly then don’t use it. That’s why hacky scripting languages like Python keep getting invented every couple of years - for people who can’t write C
Adopting the approach of no raw pointers, encapsulation, use of bounds checking, parameter checking, static analysis, multiple compilers, all warnings errors, testing and the use of tools that check memory and coverage it should be very very rare to have any memory related issues in production.
In my experience the main issues are around interpretation of requirements and implementation of those requirements (design, algorithms, knowledge).
I've thought about this a bit over the past few years and one thread seems constant, it's not the languages that are at fault, but rather the way programming is taught. New programmers think learning the language is a race, teachers/professors tasked with teaching it often rely on woefully out of date materials and frankly know little about how to teach programming. Learning C/C++, or any language for that matter, isn't a race, it's a journey, much like learning music and how to play an instrument. Sure a student can pick up an instrument and make it squeak and squawk but it certainly isn't what you would call music. It's only though rigorous practice, practice, practice and dedication to becoming better that the sound starts to improve. Leaning to program, really learning to program, is no different.
Too often students are taught from a "using the language" perspective, how to get a result, with little concern for validating every step to ensure behavior remains defined. The growth of competitive coding sites on the internet that provide preliminary code for challenges with zero validation or bounds checking just adds to the problem. Failure to teach from the perspective of what the language standard requires in order for program behavior to remain defined, or teach how to use the standards at all is yet another failure. Internet coding "courses" that in reality don't teach programming at all, but are rather limited to providing a set of problems to exercise what the student should already know further confuse students about what learning to program is. Substandard code, or tutorials on the internet is another significant problem for new programmers for the same reasons. On the flip side there are excellent coding sites, coding references, and the last draft of the language standards are available for free, but there is nothing to ensure learning programmers find them first.
I don't knock C or C++, nor do I laud Rust as a cure-all. It's not the languages that result in poor code being written or code being unsafe. The marketing push to label all C or C++ as unsafe and Rust the salvation -- is just that. It's not the first marketing push for some "greatest new thing since sliced-bread" we've seen in the programming world over the last 40 years. There is nothing wrong with trying to make it harder write unsafe code, but none of that fixes the problem of how new programmers are taught or left on their own to learn.
There are lots of ways in which machine architecture could be improved to reduce the damage caused by bugs - and lots of ways in which existing architecture features could be used in debugging and testing to catch more errors. However, hardware architectures are always compromises between performance and practicality so they're never going to give complete coverage.
Personally, I think that systems programming is probably a more tractable environment for improving code safety than general purpose programming. Allocation and deallocation of shared structures such as control blocks and buffers is usually tightly controlled - as is concurrency - and individual code paths are likely to be relatively much shorter than in an application program. A bit of bounds checking, some tightening up on pointer rules and some static analysis - particularly around copied pointers - might go a long way without having to massively overhaul existing codebases (or the people who wrote them).
First, good enough programming. We were all taught in the 1990s that good enough was good enough when Windows 3.x took over the world. It was okay that it crashed, sometimes multiple times per day. Crashes are okay so long as they don't reach a certain threshold, which is spongy and subjective and the subject of whim. Oh, look - flying toasters!
Second, Deadline Driven Development. Of course the software has bugs, but it's good enough (see above) and we've got a deadline! A meaningless deadline! A meaningless, arbitrary deadline!
Third, management engagement. As covered elsewhere in this comments section, software reliability is just one of management's many concerns and it may very well not be at the top of the list. The top of the list of course is the current deadline (see above).
Fourth, testing and code reviews. This requires a time investment that, given deadlines (see above), is one many organizations believe they cannot afford. This is a management and cultural issue.
Also, let us not forget that use-after-free and wild pointers are not the only categories of bugs in the world.
I am a leaf on the wind, watch how I code... :-)
To make my life a lot easier, I use C or C++ and
a- I usually avoid 'private's. I have everything declared as 'public'.
b- I also have most 'important' variables (except small local things like i, j, n, etc.) as globals...
c- I try to avoid #include of anything other than standard libs. I make a single huge .cpp file from everything of mine that I would have included. (Obviously including .h are OK.)
But then again...
1- I am the only one using the code which I write.
2- I never deliver. No one else ever gets their hands on it...
3- It is for research, not production or distribution.
4- It only ever runs on my own computers.
In my experience, people who write crap code with the excuses you present are also the people who have ingrained their bad habits so completely into the way they develop programs that it ends up being the only way they can do things.
Even with the new "Safe C++" paradigms, the conventional wisdom is that if you want to avoid ABI compatibility issues for a library then you must implement a C-style interface onto your library and not use anything with a C++ STL type. i.e...
void getfoo(char* buf, int length) is OK
void getfoo(std::span<char> buf) is not OK
Solving the ABI issue is really difficult, but I think that the C++ community either needs to solve it or stop proclaiming itself truly capable of being used safely.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
