[HN Gopher] The Move to Memory-Safe Programming
___________________________________________________________________
The Move to Memory-Safe Programming
Author : mfiguiere
Score : 18 points
Date : 2023-03-20 19:51 UTC (3 hours ago)
(HTM) web link (spectrum.ieee.org)
(TXT) w3m dump (spectrum.ieee.org)
| AstixAndBelix wrote:
| You'd figure we would have treated SWE like other kinds of
| engineering and avoided the pitfalls of 2000 years of civil eng
| and 200 years of electrical eng, and yet here we are in 2023
| where using at least static analysis is not the norm
| agumonkey wrote:
| SWE tried to be like EE, but in a shallow way, that's what UML
| and components were in the early 2000s, an attempts at
| emulating EE. But not on laws and principles.. just on the
| representation.
| zafka wrote:
| Just went to look to see if there were any complilers for Rust on
| Microchip or ST. Perhaps I have found a fun side project.
| RealityVoid wrote:
| STM32 are ARM based so you can build and run it today.
|
| You have libraries and support for peripherals. I know TockOS
| has support for them.
| zafka wrote:
| Thanks, If I thought a bit before I typed I would have
| realized that. Most of my code the last 12 years has been C
| on dsPICs, but coworkers have been designing in ST micros
| recently. I am not very fond of the HAL system, but lots of
| folks seem to love it. I like setting all the registers
| myself.
| RealityVoid wrote:
| > I like setting all the registers myself.
|
| I did as well, but once you write a low level driver for
| the nth time you kind of get sick of it and just want to
| build shit.
|
| I was just playing with the very opposite of that idea
| recently actually, setting the peripheral configuration
| through a taylored bytecode. Should be portable, debuggable
| with the right infrastructure, statically analyzable and
| more easily external tool generatable. Maybe blasphemous
| for embedded programmers.
| nigrioid wrote:
| What's going to happen is an overconfidence in the absence of
| memory-related issues and an increase in the exploitation of
| other classes of bugs.
| jjnoakes wrote:
| I'm not so sure. If developers and testers and QA teams can
| spend less time on a class of issues, I imagine they'll have
| more time to spend on the other classes of issues, lowering
| their exploitability as well.
| dataking wrote:
| ... which is still a net win given that logic errors, AFAIK,
| take more effort to locate and exploit. (If someone has hard
| data that prove or disprove this, please share.)
| Hemospectrum wrote:
| Your phrasing suggests that this trend is wasteful and will not
| result in a net improvement in software security overall. The
| numbers suggest otherwise. Memory corruption exploits currently
| occur twice as often as all other classes of exploits
| _combined_ , and disproportionately account for the most severe
| exploits in the relevant studies. Automating them out of
| existence means being able to spend more time and attention on
| everything else.
| waynecochran wrote:
| Demonstrates a lack of knowledge of Modern C++ when they lump C++
| in with C. Modern C++ ain't anything like C anymore.
| jstx1 wrote:
| ...started a long time ago when garbage collected languages
| became popular.
| jjnoakes wrote:
| ...and is more recently making great inroads into places where
| garbage collectors (and other features of those popular
| languages) aren't desired.
___________________________________________________________________
(page generated 2023-03-20 23:02 UTC)