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

381–390 of 427 posts

Re: The Case for Memory Safe Roadmaps

#381

Post by ryao »

xdavidliu wrote: post #190
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(); } ```

Serious C/C++ projects build with -Wall -Werror. The compiler definitely stops you then.

Re: The Case for Memory Safe Roadmaps

#382

Post by 2devnull »

UncleMeat wrote: post #346
2devnull wrote: post #308

Earlier quoted context omitted.

Ok fine, then to quote the parent to whom I was responding, “Rust advocates.” I am willing to bet that most of those “Rust advocates” are programmers who code in Rust but I’m fine with not calling them that. I agree that good programmers should be able to work in different languages, operating systems, countries.

My point is that even in a world where the government mandates that certain applications that would otherwise be written in C++ are instead written in Rust or Swift we wouldn't see some massive loss of work for people who currently program in C++.

Ok, that’s a fair point. Imagine you’re Bjarne Stroustrup, sure he doesn’t consider himself a c++ programmer, and he isn’t worried about his employment prospects, but he still has a vested interest in this issue.

Re: The Case for Memory Safe Roadmaps

#383

Post by ryao »

Zambyte wrote: post #9
dharmab wrote: post #4

Earlier quoted context omitted.

Based on early days of Rust in the Linux kernel, the segmentation of safe and unsafe code can significantly reduce the surface area within a kernel.

I realize this is beating a dead horse, but it really is a shame that microkernels didn't win for human-facing Unix systems. This issue was recognized and basically solved decades ago, and we're still almost there.

They might win in the long term. Linux is moving in a micro-kernel direction with things such as netmap, io_uring, DPDK and SPDK.

Re: The Case for Memory Safe Roadmaps

#384

Post by angiosperm »

BaculumMeumEst wrote: post #224

In the world of graphics programming, you've got: - continuing accumulation of documentation and utility libraries from Khronos - excellent learning materials from the community - tons of legacy code all using C++. https://github.com/KhronosGroup/Vulkan-Utility-Libraries https://github.com/cg-tuwien/VulkanLaunchpad https://cescg.org/our-services/an-introduction-to-vulkan/ Until I see professionals get funding to buil…

Importantly, if you look at lists of "C/C++" security holes, you find it is almost all C security holes. So when they write "C/C++" they are hoping you won't notice they are lying to you.

The residue of holes in C++ code is about the same as JS, Python, etc. So just eliminating C and C-like constructs gets you to the same level of security as the other languages.

Re: The Case for Memory Safe Roadmaps

#385

Post by School-Cotton »

dllthomas wrote: post #371
pitaj wrote: post #185

Earlier quoted context omitted.

> 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.

This is a bit like saying "you can write a buffer overflow in any turing-complete language, because you can write a C emulator, and then write the buffer overflow in C"

Re: The Case for Memory Safe Roadmaps

#386

Post by dllthomas »

School-Cotton wrote: post #385
dllthomas wrote: post #371

Earlier quoted context omitted.

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.

This is a bit like saying "you can write a buffer overflow in any turing-complete language, because you can write a C emulator, and then write the buffer overflow in C"

A bit, but in that case the buffer overflow is arguably still "in C" in a way that it isn't in my example.

As I said, you won't write a buffer overflow in rust, but unpacking why can be interesting and it doesn't end at "bounds checks".

Re: The Case for Memory Safe Roadmaps

#387

Post by slimsag »

UncleMeat wrote: post #346
2devnull wrote: post #308

Earlier quoted context omitted.

Ok fine, then to quote the parent to whom I was responding, “Rust advocates.” I am willing to bet that most of those “Rust advocates” are programmers who code in Rust but I’m fine with not calling them that. I agree that good programmers should be able to work in different languages, operating systems, countries.

My point is that even in a world where the government mandates that certain applications that would otherwise be written in C++ are instead written in Rust or Swift we wouldn't see some massive loss of work for people who currently program in C++.

We may see that the 'next generation' of 'better' programming languages (the next Swift, the next Rust, etc.) cannot easily/readily/practically become certified for government use, though, leading to less innovation long term.

For example, if this had already happened we may find today that Java is certified for use but that Rust is simply not allowed, while maybe Swift is because of Apple's backing of it.

Re: The Case for Memory Safe Roadmaps

#388

Post by [deleted] »

slimsag wrote: post #387
UncleMeat wrote: post #346

Earlier quoted context omitted.

My point is that even in a world where the government mandates that certain applications that would otherwise be written in C++ are instead written in Rust or Swift we wouldn't see some massive loss of work for people who currently program in C++.

We may see that the 'next generation' of 'better' programming languages (the next Swift, the next Rust, etc.) cannot easily/readily/practically become certified for government use, though, leading to less innovation long term. For example, if this had already happened we may find today that Java is certified for use but that Rust is simply not allowed, while maybe Swift is because of Apple's backing of it.

[deleted]

Re: The Case for Memory Safe Roadmaps

#389

Post by stouset »

estebank wrote: post #283
stouset wrote: post #254

Earlier quoted context omitted.

I don’t think most Rust programmers agree it’s impossible at all. There’s always unsafe. I can make a pointer to anywhere by hand and write to it. That would involve some very intentional work, but I could do it if I wanted to.

There's a difference between "chamber a round, remove the safety, aim at the foot, shoot" and "open the kitchen faucet, leg gets blown off".

Yes of course. But the GP said it isn’t possible. It is. It’s not even hard.

But I did disclaim that it had to be somewhat intentional.

Re: The Case for Memory Safe Roadmaps

#390

Post by kelipso »

VerminOctopus1 wrote: post #307
kelipso wrote: post #131

Earlier quoted context omitted.

Language wise, Python is basically just Perl with its arms cut off and bunch of makeup added. It's just very popular in the scientific community, so they have to add it.

I don’t know how you can possibly come away with this conclusion after studying both languages. Maybe if your point of reference is an ancient version of Python?

Yes it is and current Python is basically just an object oriented system hacked on top of ancient Python. The underlying elements beneath the syntax is basically all the same.
Post reply on HN