4 ms·

The term "memory safe language" (also used in the "Securing Open Source Software Act") is a misnomer. The report kind of acknowledges this "Even with a memory

by scj 4y ago

The term "memory safe language" (also used in the "Securing Open Source Software Act") is a misnomer. The report kind of acknowledges this "Even with a memory safe language, memory management is not entirely memory safe" but then presses on with the term anyway. I think they're trying to combine the concepts of languages that have GCs and prevent buffer overflows into a catch-all term, but "memory safe language" isn't a good choice. Non-programmers might take the term at face value. It's kind of like using the term "safe flame thrower", except no one would be lulled into a false sense of security with that one. Don't get me wrong, I'd rather use a "safer flame thrower" than a "flame thrower", but I also wouldn't trust anyone selling me a "safe flame thrower". The above is my best Dijkstra impersonation.

zelon88 4y ago
Non programmers reading this will start throwing it around at meetings prompting some kind of explanation or response from more technical teams. This pressure on the technical teams will probably result in a net reduction of memory errors over time.
- recuter 4y ago
  As in the managers will forget about this and move on to the next fad shortly thereafter?
rowanG077 4y ago
"safe" doesn't mean "cannot go wrong". See terms such as safety belt or safety shoes, no one expects those to be infallible. It's simply an extra layer of defense.
IshKebab 4y ago
What about safety net or safety belt or... a safe? None of those are infallible either. "Memory safe language" is a perfectly good term for the moment since most languages fall square into "completely unsafe" or "completely safe with the ability to be unsafe in special circumstances". I don't know of any that are "fairly safe". Maybe something like Carbon will be like that.
tialaramex 4y ago
The excuse that "safety" could mean a lot of things, and these languages don't solve all of those things, so therefore they shouldn't count and we should stop saying C and C++ are unsafe is really tired at this point. The current set of papers for WG21 the "C++ Standards Committee" includes more than one taking this stance, but obviously the standout is P2687 from Bjarne Stroustrup and Gabriel Dos Reis. Bjarne and Gaby describe the situation (in which the US Federal Government has noticed that there's a problem) as an "Emergency" https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2687r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p26... P2687R0 is an initial draft (even by R0 standards it looks very hastily thrown together) but it wrings its hands about the propensity of programmers to write bad code, and then it offers a list of eight kinds of (un)safety, including "delivering a result in 1.2ms to a device supposedly responding to an external event in 1ms". Alas, although C++ doesn't really help you with any of this list, other languages don't solve all of them and so why bother right? It also takes pains to group together intractable problems (e.g. dynamic allocation but with assurance of no leaks) with solved problems (e.g. preventing use-after-free). The R0 draft doesn't really spend much time explaining how, if at all, they would solve the problem (beyond vaguely "static analysis" so it can't be critiqued on that basis. I'm sure the committee (of which both Bjarne and Gaby are members) will look favourably on this sort of work, but nobody in government should take anything like this seriously until the actual problem gets solved, ie the programs stop being full of memory bugs.
- pjmlp 4y ago
  I think that given the cultural issues in some circles that render most of these attempts as valiant knights trying to defeat dragons, many will only cave in when the goverments decide using this kind of languages is akin to other unsafe products and require similar levels of compliance. Software can still be delivered in those languages, after all the goverments themselves have millions invested into such codebases, but it comes with an extra price tag versus other safer alternatives.

by scj 4y ago

zelon88 4y ago

Non programmers reading this will start throwing it around at meetings prompting some kind of explanation or response from more technical teams. This pressure on the technical teams will probably result in a net reduction of memory errors over time.

recuter 4y ago
As in the managers will forget about this and move on to the next fad shortly thereafter?

rowanG077 4y ago

"safe" doesn't mean "cannot go wrong". See terms such as safety belt or safety shoes, no one expects those to be infallible. It's simply an extra layer of defense.

IshKebab 4y ago

What about safety net or safety belt or... a safe? None of those are infallible either. "Memory safe language" is a perfectly good term for the moment since most languages fall square into "completely unsafe" or "completely safe with the ability to be unsafe in special circumstances". I don't know of any that are "fairly safe". Maybe something like Carbon will be like that.

tialaramex 4y ago

The excuse that "safety" could mean a lot of things, and these languages don't solve all of those things, so therefore they shouldn't count and we should stop saying C and C++ are unsafe is really tired at this point. The current set of papers for WG21 the "C++ Standards Committee" includes more than one taking this stance, but obviously the standout is P2687 from Bjarne Stroustrup and Gabriel Dos Reis. Bjarne and Gaby describe the situation (in which the US Federal Government has noticed that there's a problem) as an "Emergency" https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2687r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p26... P2687R0 is an initial draft (even by R0 standards it looks very hastily thrown together) but it wrings its hands about the propensity of programmers to write bad code, and then it offers a list of eight kinds of (un)safety, including "delivering a result in 1.2ms to a device supposedly responding to an external event in 1ms". Alas, although C++ doesn't really help you with any of this list, other languages don't solve all of them and so why bother right? It also takes pains to group together intractable problems (e.g. dynamic allocation but with assurance of no leaks) with solved problems (e.g. preventing use-after-free). The R0 draft doesn't really spend much time explaining how, if at all, they would solve the problem (beyond vaguely "static analysis" so it can't be critiqued on that basis. I'm sure the committee (of which both Bjarne and Gaby are members) will look favourably on this sort of work, but nobody in government should take anything like this seriously until the actual problem gets solved, ie the programs stop being full of memory bugs.

pjmlp 4y ago
I think that given the cultural issues in some circles that render most of these attempts as valiant knights trying to defeat dragons, many will only cave in when the goverments decide using this kind of languages is akin to other unsafe products and require similar levels of compliance. Software can still be delivered in those languages, after all the goverments themselves have millions invested into such codebases, but it comes with an extra price tag versus other safer alternatives.