SoylentNews is people
SoylentNews
Memory safe programming languages are on the rise. Here's how developers should respond:
Developers across government and industry should commit to using memory safe languages for new products and tools, and identify the most critical libraries and packages to shift to memory safe languages, according to a study from Consumer Reports.
The US nonprofit, which is known for testing consumer products, asked what steps can be taken to help usher in "memory safe" languages, like Rust, over options such as C and C++. Consumer Reports said it wanted to address "industry-wide threats that cannot be solved through user behavior or even consumer choice" and it identified "memory unsafety" as one such issue.
The report, Future of Memory Safety, looks at range of issues, including challenges in building memory safe language adoption within universities, levels of distrust for memory safe languages, introducing memory safe languages to code bases written in other languages, and also incentives and public accountability.
During the past two years, more and more projects have started gradually adopting Rust for codebases written in C and C++ to make code more memory safe. Among them are initiatives from Meta, Google's Android Open Source Project, the C++-dominated Chromium project (sort of), and the Linux kernel.
In 2019, Microsoft revealed that 70% of security bugs it had fixed during the past 12 years were memory safety issues. The figure was high because Windows was written mostly in C and C++. Since then, the National Security Agency (NSA) has recommended developers make a strategic shift away from C++ in favor C#, Java, Ruby, Rust, and Swift.
The shift towards memory safe languages -- most notably, but not only, to Rust -- has even prompted the creator of C++, Bjarne Stroustrup and his peers, to devise a plan for the "Safety of C++". Developers like C++ for its performance and it still dominates embedded systems. C++ is still way more widely used than Rust, but both are popular languages for systems programming.
[...] The report highlights that computer science professors have a "golden opportunity here to explain the dangers" and could, for example, increase the weight of memory safety mistakes in assessing grades. But it adds that teaching parts of some courses in Rust could add "inessential complexity" and that there's a perception Rust is harder to learn, while C seems a safe bet for employability in future for many students.
[...] To overcome programmers' belief that memory safe languages are more difficult, someone could explain that these languages "force programmers to think through important concepts that ultimately improve the safety and performance of their code," the report notes.
Are you or your employer using or considering memory safe languages, and if so what is your opinion of them in your particular sphere?
(Score: 5, Insightful) by Anonymous Coward on Thursday January 26 2023, @09:25PM (2 children)
In a nutshell, static checking of existing C and C++ code can do a lot of what Rust and friends do without forcing a wholesale re-write of billions of lines of existing code. I agree, and have wondered what kinds of types and/or qualifiers could be added to C in order to support such safety. Then it would be a matter of adding some compiler warnings and actually requiring releases to compile without triggering them. There's an awful lot of code out there that honks when compiled with -Wall for no legit reason other than people not wanting to clean up their code.
(Score: 4, Informative) by turgid on Thursday January 26 2023, @09:37PM (1 child)
Bingo!
When you go to write new code you should set, as a bare minimum, on the compiler command line -Wall -Werror -pedantic. You should also do TDD. You shouldn't write a line of code without a unit test case with at least one assert() in it.
In recent years, gcc has become very helpful at telling you when you might overflow string buffers. In years past, you used to have to pay for third party static analysis tools to do that sort of things.
Make sure you understand the difference between the BSS, heap and stack. Understand how array bounds work. Understand array dimensions and pay close attention to the types. Read the C Programming FAQ.
Understand that address 0 is special. Understand that memory comes uninitialised by default unless you declare static. Do you know what volatile is for? What's the difference between an integer and a pointer? What's special about function pointers?
What are the catches with string literals vs arrays of char?
Which C library functions are unsafe, and were therefore bad designs? Which C library functions are better?
When is using malloc() and free() a bad idea? What are the alternatives?
What should happen when the machine runs out of virtual memory?
How are mutexes implemented at the hardware level? Cache coherency? Bus snooping?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2, Funny) by shrewdsheep on Friday January 27 2023, @09:52AM
You should order some new.