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

371–380 of 427 posts

Re: The Case for Memory Safe Roadmaps

#371

Post by dllthomas »

pitaj wrote: post #185
jvanderbot wrote: post #151

Earlier quoted context omitted.

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.

You're more right than wrong, but I want to push back just a little. You can write a buffer overflow in safe rust if you store multiple things in the same array and work with indices rather than slices. Of course the risk is bounded by what shares an array, and it's more awkward than doing it any of several right ways. You won't write a buffer overflow in safe rust... but you can if you want to.

Re: The Case for Memory Safe Roadmaps

#372

Post by School-Cotton »

jaisjdkaaaej wrote: post #358
School-Cotton wrote: post #303

Earlier quoted context omitted.

> At the interface to _literally any_ system call, unsafe starts to creep out. Either in the wrapper implementation, or in the interface _to_ the system, or even leaking through the wrapper to the caller. It’s quite rare to have to make syscalls directly in Rust, just like it is in c++. Most code in any large enough system is related to the internal logic of the system, not to its interface with the outside world. An…

And that's the problem, I do have to make syscalls directly quite often, and so I dislike Rust immensely. There are literally dozens of us at least, but the only people ever talking about Rust on the internet always like to drag C into the conversation for whatever reason even though they are always C++ programmers.

That's fair! If you are doing something low-level enough that the bulk of the work is interfacing directly with a C library (or with the kernel, in the case of syscalls) then C might make more sense than Rust.

Re: The Case for Memory Safe Roadmaps

#373

Post by jebarker »

hardware2win wrote: post #179
jebarker wrote: post #127

Earlier quoted context omitted.

Reviewing C/C++ code for memory safety is probably a good use case for LLMs actually. Writing memory safe code from scratch is a much bigger ask.

I bet many, many false alarms

Perhaps, but reviewing code for memory safety issues is a more well defined task than general code generation so LLMs can be more easily trained to get better at it.

Re: The Case for Memory Safe Roadmaps

#374

Post by osigurdson »

bumby wrote: post #182
osigurdson wrote: post #147

Earlier quoted context omitted.

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.

Agree. Leaders (though I think "Gatekeepers" is a more accurate term in this context) should not stand in the way of anyone's awesomeness.

Re: The Case for Memory Safe Roadmaps

#375

Post by marwis »

jaisjdkaaaej wrote: post #359
jvanderbot wrote: post #151

Earlier quoted context omitted.

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…

People writing C are the people that really do have to make syscalls directly, or use weird calling conventions, or whatever all the time. I see Rust replacing C++ but I have a hard time seeing it replace C because the people that desired and/or could tolerate safety, like you said, are already not writing C for the most part. That group has been firmly C++ for a long time.

> People writing C are the people that really do have to make syscalls directly,

Not really. See for example desktop Linux (i.e. Gnome).

Re: The Case for Memory Safe Roadmaps

#376

Post by trealira »

jandrewrogers wrote: post #292
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.

You can have underflow/overflow trapping today if you want it in C++. Most people don't use it, at least not in release builds, because of the performance cost.

It doesn't catch all signed overflow. If you define a function like this:

  int8_t abs8(int8_t n) {
      return (n >= 0) ? n : -n;
  }
Even with `-ftrapv`, evaluating abs8(-128) will produce -128, because 127 is the maximum value for a signed 8-bit integer (so trying to get 128 wraps around to -128), but this isn't caught. However, both Rust and Ada do catch this. This article highlights this difference between C and Ada:

https://borretti.me/article/signed-integers-asymmetrical

I know Rust catches it because after I read that article, I tested it with Rust in debug mode.

Re: The Case for Memory Safe Roadmaps

#377

Post by im3w1l »

jandrewrogers wrote: post #292
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.

You can have underflow/overflow trapping today if you want it in C++. Most people don't use it, at least not in release builds, because of the performance cost.

I think the question we have to ask is why it has such a performance cost, and how we can circumvent it.

There are likely multiple necessary changes for it to be fast. One part is implementing the check quickly, this could be hardware assisted. Another is addressing all the optimizations the compiler does by asuming that there is no overflow, and figuring out alternative ways to get the compiler to emit fast code.

Re: The Case for Memory Safe Roadmaps

#378

Post by School-Cotton »

jvanderbot wrote: post #327
School-Cotton wrote: post #303

Earlier quoted context omitted.

> At the interface to _literally any_ system call, unsafe starts to creep out. Either in the wrapper implementation, or in the interface _to_ the system, or even leaking through the wrapper to the caller. It’s quite rare to have to make syscalls directly in Rust, just like it is in c++. Most code in any large enough system is related to the internal logic of the system, not to its interface with the outside world. An…

OK this is reasonable. Perhaps my experience skews towards the lower-level a bit too much. And it's also reasonable I'm misusing the language given it's not my day job. To answer your question, I'm referring to much of the networking code in socket2 / socket, which uses MaybeUninit when doing non-standard stuff like forming your own packets. (RAW)

Yep, I definitely buy that if you're doing very low-level stuff, C or C++ might be more ergonomic than Rust. But I don't think that covers most of the real-world use of C++.

I'm not too familiar with `socket2` but normally in Rust to construct a buffer with arbitrary bytes in safe code you would first zero it out and then write it. Using `MaybeUninit` there is presumably just a micro-optimization to avoid having to memset things to zero.

Re: The Case for Memory Safe Roadmaps

#379

Post by shikon7 »

jvanderbot wrote: post #276
jerf wrote: post #268

Earlier quoted context omitted.

Because "significantly more safe than C", while true, is also irrelevant. I want safe, not "safer than grotesquely unsafe". Unfortunately, for all the advances C++ has made, it is still in the "unsafe at any speed" class. It is difficult to escape the foundation of unsafety the entire C++ edifice rests on. (At least, without further support. I consider "C/C++ with high quality static analysis" to be de facto distinct…

Separating safe C/C++ from everyday C/C++ is not fair, in my opinion, but I get your point: If it can be abused it will be, either by accident, inexperience, or maliciousness. Once you separate C/C++ into safe and unsafe cateogries, and admit that Rust has unsafe uses that are "just so much harder to use", we're clearly defining a gradient: C/C++, safer C/C++ subset or maybe Unsafe Rust, safer Rust, ...

Sure you can use safe C++ with some effort, but the libraries you use most likely still use unsafe C/C++. For Rust, I expect that the libraries are much safer in general.

Re: The Case for Memory Safe Roadmaps

#380

Post by ryao »

zozbot234 wrote: post #351
ryao wrote: post #339

Earlier quoted context omitted.

What is the memory-safe subset of Java? Java is memory safe by definition. Sadly, the definition might not give people what they want, which is bug-free code.

If you use sun.misc.Unsafe you've left the memory-safe subset.

Thanks. I had no idea that existed.
Post reply on HN