Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Case for Memory Safe Roadmaps

nsa.gov

Post reply on HN
Print view View original

181–190 of 427 posts

Re: The Case for Memory Safe Roadmaps

#181

Post by School-Cotton »

jvanderbot wrote: post #151
jerf wrote: post #22

Earlier quoted context omitted.

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 Ru…

Rust is memory safe by default, with unsafety as an optional feature that you basically never need to use unless you’re writing extremely low-level code, need absolute maximum performance, or are interfacing with libraries written in other languages.

C++ is unsafe by default.

Of course it’s just as easy to write bugs in unsafe Rust as it is in C++ (actually, it’s probably even easier), but defaults matter.

Re: The Case for Memory Safe Roadmaps

#182

Post by bumby »

osigurdson wrote: post #147
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 think people should take responsibility for their own awesomeness.

I assume that includes leaders taking responsibility for the organization they are paid to lead. That includes investing in their coworkers' "strategic awesomeness" via training.

Re: The Case for Memory Safe Roadmaps

#183

Post by VikingCoder »

citrin_ru wrote: post #177
hsbauauvhabzb wrote: post #77

Earlier quoted context omitted.

Sure, but even the best programmers can write buffer overflows and other memory issues. Not that average shops have any interest in actually training people, though.

Best programmers tend to work on the most complex software though. There are small and relatively simple C/C++ programs around which have no know memory issues (but a person with minimal viable knowledge can introduce new bugs even there and that's where training would be useful).

I worked with someone who said it great once. I wish I'd written it down. It was something like,

"I'd rather use a threading library written by one great programmer than by ten average programmers."

Re: The Case for Memory Safe Roadmaps

#184

Post by ahmedfromtunis »

gosub100 wrote: post #105

Can someone explain why we can't double-down on C++ and, through compiler wizardry and reduction in toolset (say, strings can only be fixed-size at 32 chars, 64, or 256 long. No raw pointers, allocator zeroes out all freed memory), achieve a memory-safe language? Obviously, making certain concessions would be a deal-breaker for some, but it might be viable for legacy codebases. If you were to try to make C++ memory-s…

I think this is, realistically, the easiest way to solve the problem. That, or a totally different language that is (somehow) a drop-in replacement for c/c++.

I'm in no way an expert in any aspect that relates to this problem, but it's reasonable to believe that it would be but a mildly challenging task if companies like Google, meta, Microsoft and the likes joined forces.

A year of concentrated efforts might be sufficient to rid us with this problem once and for all.

Re: The Case for Memory Safe Roadmaps

#185

Post by pitaj »

jvanderbot wrote: post #151
jerf wrote: post #22

Earlier quoted context omitted.

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 Ru…

> I can write a buffer overflow in any language. ... It's perfectly simple to trash memory in Rust.

Not in safe Rust.

Re: The Case for Memory Safe Roadmaps

#186

Post by corethree »

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…

Rust is a little too safe imo. I want a rust with just shared pointers and no move semantics. I guess go would be it? But go is too opinionated with a bunch of stupid go specific philosophies like the weird error handling and the stupid packaging rules.

Go is also opinionated with concurrency. So that's an issue too.

Re: The Case for Memory Safe Roadmaps

#187

Post by UncleMeat »

munk-a wrote: post #159
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?

And this still permits oodles of memory safety issues. You can have lifetime problems with stack-use-after-return. You can have bounds checking issues on stack allocated arrays. You can have data leakage through use of uninitialized memory.

And while there are some kinds of applications where never performing heap allocations is viable, this design is simply not an option for a huge number of applications.

Re: The Case for Memory Safe Roadmaps

#188

Post by bumby »

seanw444 wrote: post #74
CJefferson wrote: post #36

Earlier quoted context omitted.

Next thing they'll be giving requirements for people building bridges, houses, and gas and electricity fittings. Seriously, I think the time has long since passed software needs regulating. It's a major part of modern society, and as far as I'm aware, most people aren't opposed to building standards in principle.

The wild west had a lot less danger and death than Hollywood makes it out to seem. Likewise, I'm going to miss the internet and computing as we know it now when it's regulated to shit like everything else. Nothing nice ever lasts. Complete safety, or actual freedom. Pick one. You can't have both.

>Complete safety, or actual freedom. Pick one. You can't have both.

False dichotomies aren't helpful and underscore lazy thinking. The real world is full of nuance, and so should our policies. Using a risk-based approach is probably more appropriate than an all-or-nothing policy.

Re: The Case for Memory Safe Roadmaps

#189

Post by baseballdork »

zaphar wrote: post #109
baseballdork wrote: post #67

Earlier quoted context omitted.

Let's be real. Creating an air gap hasn't stopped a very few, unlimited resource, APTs. Don't let perfect be the enemy of good enough.

To really be real if air-gapping is a significant mitigation for your risk profile then you are likely the target of one of those rare APT's. You should probably also be using a memory safe language if you think you need air gapping.

I agree, but I don't think the OP was saying APTs are in their threat profile.

Re: The Case for Memory Safe Roadmaps

#190

Post by xdavidliu »

DeathArrow wrote: post #65

Isn't C++ with RAII reasonably safe? I tried to learn/like Rust but it's against how I use to think. If no friendlier safe high speed programming language appears, I rather use C/C++ and trade safety for friendliness.

I was shocked to learn that reaching an end of a function without returning is actually UB and the compiler doesn't stop you; only warns. For example:

```

class Foo;

Foo get_foo() { std::cout int main() { const auto foo = get_foo(); }

```

Post reply on HN