The Case for Memory Safe Roadmaps • Hacker News Board

Re: The Case for Memory Safe Roadmaps

#151

Post by jvanderbot » Tue, Dec 12, 2023, 3:03 PM UTC

jerf wrote: post #22

wodow wrote: post #6

Their "Appendix: Memory Safe Languages" lists: C#, Go, Java, Python, Rust & Swift

Really, the only memory unsafe languages still in use are C and C++. If it weren't for the behemoth of legacy code we'd really have this problem more-or-less licked. Unfortunately, that behemoth is still rampaging across the landscape. "Rewrite it in Rust" gets a bit of pushback, perhaps even justified, but at this point in time I'll take anything that just reduces that behemoth in size. The journey of a thousand mil…

Why are C and C++ considered the same, in these conversations?

C++ at least has tools to make life significantly more safe. I can write a buffer overflow in any language, and on the scale of difficulty, ASM-C-C++-Rust-Python covers my experience (from easiest to fuck up to hardest).

Yet nobody is calling for us to rewrite everything in python. Why is the line drawn at Rust? It's perfectly simple to trash memory in Rust.

Re: The Case for Memory Safe Roadmaps

#152

Post by CoastalCoder » Tue, Dec 12, 2023, 3:03 PM UTC

jmclnx wrote: post #32

I advise training programmers instead of throwing them in front of a screen without any training. Companies these days provides no training at all. When I was hired over 40 years ago, I spent plenty of time being trained for my first 3 months. Now, nothing, and you if you want to train a new person, you do it on your own time.

I wonder of part of the issue is that 40 years ago, people typically stayed much longer with companies.

(I actually don't know what the norm was. My dad was an EE for the defense industry, and IIRC he worked for 3 different employers over his career.)

Re: The Case for Memory Safe Roadmaps

#153

Post by chasil » Tue, Dec 12, 2023, 3:03 PM UTC

local_crmdgeon wrote: post #90

projektfu wrote: post #44

Earlier quoted context omitted.

Ada people scratching their heads....

How many of them are left? I thought it was very much a dead language

Far from it.

"SQL/PSM (SQL/Persistent Stored Modules) is an ISO standard mainly defining an extension of SQL with a procedural language for use in stored procedures... SQL/PSM is derived, seemingly directly, from Oracle's PL/SQL. Oracle developed PL/SQL and released it in 1991, basing the language on the US Department of Defense's Ada programming language. However, Oracle has maintained a distance from the standard in its documentation. IBM's SQL PL (used in DB2) and Mimer SQL's PSM were the first two products officially implementing SQL/PSM. It is commonly thought that these two languages, and perhaps also MySQL/MariaDB's procedural language, are closest to the SQL/PSM standard. However, a PostgreSQL addon implements SQL/PSM (alongside its other procedural languages like the PL/SQL-derived plpgsql), although it is not part of the core product."

https://en.wikipedia.org/wiki/SQL/PSM

Re: The Case for Memory Safe Roadmaps

#154

Post by 2devnull » Tue, Dec 12, 2023, 3:04 PM UTC

slimsag wrote: post #80

xnorswap wrote: post #19

Earlier quoted context omitted.

It is ridiculous to equate a recommendation and a mandate.

Well, there are groups that want a government mandate for this, though. If you don't know, Consumer Reports is paid by groups interested in encouraging the government to apply regulations to certain areas. A bike helmet manufacturer may pay them to create a report, host events, and otherwise lobby on their behalf to e.g. create regulations about people needing to use bike helmets. It is my understanding that many Rus…

Rust programmers want the government dollarinos? Amazing. It did feel a bit coordinated.

Re: The Case for Memory Safe Roadmaps

#155

Post by OrvalWintermute » Tue, Dec 12, 2023, 3:04 PM UTC

lambdaone wrote: post #59

"Undefined behavior" in general is a nightmare. After memory safety, the next target should be the enforcement of underflow/overflow trapping. With the exception of the intentional use to implement modular arithmetic, underflow/overflow should always be an error condition.

most consumer operating systems are inherently non-deterministic which I put right in there next to undefined behavior (some people say it is a different thing).

Re: The Case for Memory Safe Roadmaps

#156

Post by osigurdson » Tue, Dec 12, 2023, 3:04 PM UTC

brookst wrote: post #144

jmclnx wrote: post #32

I advise training programmers instead of throwing them in front of a screen without any training. Companies these days provides no training at all. When I was hired over 40 years ago, I spent plenty of time being trained for my first 3 months. Now, nothing, and you if you want to train a new person, you do it on your own time.

Not to worry! In the future most programmers will undergo tens of thousands of GPU hours of training.

We will see. I suspect things will not turn out as expected.

Re: The Case for Memory Safe Roadmaps

#157

Post by RhodesianHunter » Tue, Dec 12, 2023, 3:04 PM UTC

anthk wrote: post #111

wodow wrote: post #6

Their "Appendix: Memory Safe Languages" lists: C#, Go, Java, Python, Rust & Swift

>Java Java it's a pest fest for exploits. From those, I'd choose Go, C# (and not totally sure because of AOT/JIT's) and Rust.

>Java it's a pest fest for exploits.

Sure, if you haven't used it since the nineties and pay zero attention to new development.

Re: The Case for Memory Safe Roadmaps

#158

Post by afdbcreid » Tue, Dec 12, 2023, 3:05 PM UTC

rwmj wrote: post #85

Given the vast amount of C/C++ around, much which will never be rewritten, I wonder if bounds checking compilers should be considered?

Bounds checking will sure solve some of the problems, but it will not solve all of them, perhaps not even most of them. You'd still got: UAF, iterator invalidation, etc.. And not even all code can be bounds checked, you need to know the length for that (which means using new types such as std::span or having to annotate your functions with a compiler attribute, to be able to also bound-check pointers).

Re: The Case for Memory Safe Roadmaps

#159

Post by munk-a » Tue, Dec 12, 2023, 3:05 PM UTC

jmclnx wrote: post #32

I advise training programmers instead of throwing them in front of a screen without any training. Companies these days provides no training at all. When I was hired over 40 years ago, I spent plenty of time being trained for my first 3 months. Now, nothing, and you if you want to train a new person, you do it on your own time.

As someone who has worked in C/C++ on teams for a while. My personal opinion is that safe C++ programmers never use pointers - put everything on the stack and use (usually const) references.

But I've really got to ask - at that point do you really want to program in C++ anymore or is it just better to use a safer language that removes pointers entirely?

Re: The Case for Memory Safe Roadmaps

#160

Post by brookst » Tue, Dec 12, 2023, 3:05 PM UTC

logicchains wrote: post #83

lambdaone wrote: post #59

"Undefined behavior" in general is a nightmare. After memory safety, the next target should be the enforcement of underflow/overflow trapping. With the exception of the intentional use to implement modular arithmetic, underflow/overflow should always be an error condition.

Not everything is a server facing malicious actors. Forcing underflow/overflow trapping would absolutely harm optimisation and performance for use-cases where security is a non-issue.

I want to agree, but I’ve seen too many cases where code written for a narrowly scoped purpose finds its way into a totally different environment where the original assumptions no longer hold. Maybe it’s worth a tax on constrained use cases in the name of having fewer time bombs out there?