I think your security background is coloring your perception of the term memory safety. Specifically the requirement that the various issues lead to exploitation. These issues can lead to many other issues that are not vulnerability in the security sense, e.g. data corruption, incorrect (but not insecure) behavior, performance issues, and more. I don't think any of those were ever dismissed or excluded from memory safety discussion. Infosec circles tend to evaluate most ideas in the context of (anti)exploitation, and the rest of programming tends to focus on what the cool kids argue (that is they often weigh security concerns higher than other issues as well), so the other problems caused by double-free or buffer overruns (etc) just may not have been given as much weight in your mind.

▲

tptacek 5 days ago | parent [-]

"Memory safety" is a security term, not a PLT term.

▲

SkiFire13 5 days ago | parent | next [-]

That's a statement without source and even if it was widely accepted as true it doesn't imply the fact that something needs to be exploitable to be considered a security issue. We are full of CVEs without a known way to be exploited.

	▲	tptacek 4 days ago \| parent [-]
		Non-falsifiable statement is non-falsifiable.

▲

Sharlin 4 days ago | parent | prev [-]

First off, in any and every engineering discipline it would be absurd to claim that "safety" only means security against intentional malice.

Second, the burden of proof goes the other way. It’s absurd to claim that UB is safe unless proven otherwise. Unsafety must obviously be the default assumption.