Page 55 - EE Times Europe Magazine – June 2024

EE|Times EUROPE 55

Is C/C++ Memory-Safe?

CODING STANDARDS you’re allowed to exempt yourself from any rule you like, as long as you
Wintle cautioned developers against overdependence on a give a justification.”
memory-safe language. “It’s like having a cushion—the fact that For example, the standard says not to use dynamic memory allo-
something else is looking out for problems for you. I think that’s a bit cation but adds that if you do, you should do so in a particular way.
dangerous. You have to be careful with what some of the software tools “Engineers can still make the decisions to use riskier memory tech-
can provide, too,” as the tools’ promised functionality can likewise niques,” Massey said.
provide a false sense of security.
EE Times Europe asked Wintle whether the diligent use of formal A HYBRID APPROACH
coding practices, such as the MISRA C standard, would be beneficial. “I O’Brien said the wisdom of adopting a hybrid approach based on
think coding styles change between different environments, organi- C/C++ and Rust “depends on the project,” adding, “One thing that
zations and systems,” he said. “The general practices are the same, so isn’t talked about enough with embedded development, and spe-
making sure that things are modular, and are able to be unit-tested cifically with languages like Rust, is that a lot of embedded code is
as a separate entity rather than as a whole system, is something that inherently unsafe.
everyone would agree on. “This is because when you’re talking to hardware peripherals,
“If you apply at least a basic level of coding practices, I think it really for example, you are writing data into memory addresses that are
helps, but you’ve got no control over someone else’s coding practice or inherently unsafe,” she explained. “There is no way that it can be
style,” Wintle added. recognized as safe by a compiler, since it is unable to systematically
Massey called MISRA C a good set of standards but cautioned that decide what’s safe and unsafe. For example, in Rust, if you are writ-
there’s still a human element to consider, noting that “under MISRA, ing firmware for a sensor, you’re going to have to wrap everything
in unsafe blocks, so the compiler
allows it.
“I’d say that Rust is actually
less safe than C, because in C, the
language is all designed around
writing unsafe code,” O’Brien said.

MAKING THE COMMERCIAL
CASE
Don’t expect the embedded com-
munity to ditch C/C++ for a
memory-safe alternative anytime
soon. Clearly, embedded devel-
opers are not of one mind about
adopting a language like Rust.
The scale of change required
by stakeholders is staggering.
However, Rust is clearly a viable
contender for embedded systems,
as Bluefruit’s Massey observed.
Wintle looked to inject a dose
of reality into initiatives to
improve the messaging around a
language swap: “Where there is
a commercial reasoning behind
swapping, other than [just] the
‘need’ to, it would make sense.
But the benefits are not guaran-
teed, because if you follow good
programming practices, you
should end up in the same place”
either way.
“As for initiatives, I don’t see
how it would work, other than
some form of financial encourage-
ment, but that feels the wrong way
around,” Wintle said. “It feels like
politics is driving industry, which is
not the right way to do this.” ■
REFERENCE
1 Kernighan, B.W., & Ritchie, D.M.
(1988). “The C Programming Lan-
The Tiobe Index has collected nearly 25 years of data about programming languages and tracked guage.” 2nd edition. Prentice Hall
their popularity over time. (Source: The Tiobe Index, May 2024) Software Series.

www.eetimes.eu | JUNE 2024