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

Smart pointers for the kernel

lwn.net

Post reply on HN
Print view View original

101–110 of 120 posts

Re: Smart pointers for the kernel

#101

Post by hansvm »

littlestymaar wrote: post #95
hansvm wrote: post #36

Earlier quoted context omitted.

This is giving Rust a bit too much credit though. - Memory leaks are not just possible in Rust, they're easy to write and mildly encouraged by the constraints the language places on you. IME I see more leaks in Rust in the wild than in C, C#, Python, C++, ... - You can absolutely have data races in a colloquial sense in Rust, just not in the sense of the narrower definition they created to be able to say they don't h…

There's some truth in what you're saying, but its also wildly exaggerated and “everything that is exaggerated is insignificant”.

> but its also wildly exaggerated

Such as?

> everything that is exaggerated is insignificant

But are the non-exaggerated things significant?

Re: Smart pointers for the kernel

#102

Post by Ar-Curunir »

uecker wrote: post #60
Ar-Curunir wrote: post #56

Earlier quoted context omitted.

my comment (and indeed in this entire comment chain) is within the context of memory safety. This should have been clear because of the focus on unsafe, which, compared to normal Rust, relaxes only memory safety. Obviously if you want to get formal guarantees beyond that property, you have to reason about safe code also. (Also, the comparison in this entire chain is against C, and the latter is better than Rust in th…

Yes, this discussion is about memory safety, but this does not invalidate my argument. There is no point in only auditing your code with respect to memory safety, so the argument that you can simply ignore everything outside "unsafe" blocks is simply wrong.

You can’t expect to hop in the middle of an ongoing discussion, ignore the context of that discussion, and then hope to be taken seriously.

Re: Smart pointers for the kernel

#103

Post by uecker »

dwattttt wrote: post #98
uecker wrote: post #91

Earlier quoted context omitted.

In other words, somebody made an error somewhere.

You're thinking of C; Rust forced that somebody to write unsafe near it to create the bug.

The bug that can lead to a violation of assumptions required for safety of the unsafe block can be elsewhere. One can hope that it is near the bloc, but there is nothing in Rust enforcing this.

Re: Smart pointers for the kernel

#104

Post by uecker »

lostdog wrote: post #97
uecker wrote: post #92

Earlier quoted context omitted.

Let's discuss this example: https://github.com/ejmahler/transpose/blob/e70dd159f1881d86a... The code is buggy. Where is the bug?

The most common bug in that type of code is mixing up x and y, or width and height somewhere in your loops, or maybe handling partial blocks. It's not really what Rust aims to protect against, though bounds checking is intended to be helpful here. I don't get the argumentshere. In practice, Rust lowers the risk of most of your codebase. Yeah, it doesn't handle every logic bug, but mostly you can code with confidence,…

The issue is a memory safety issue, which Rust aims to protect against.

But I am not saying Rust is bad. My issue is the complete unreasonable exaggeration in propaganda from "C is completely dangerous and Rust is perfectly safe". And then you discuss and end up with "Rust does not protect against everything, but it still better", which could be the start of a reasonable discussion of how much better it actually is.

Re: Smart pointers for the kernel

#105

Post by uecker »

NobodyNada wrote: post #99
uecker wrote: post #92

Earlier quoted context omitted.

Let's discuss this example: https://github.com/ejmahler/transpose/blob/e70dd159f1881d86a... The code is buggy. Where is the bug?

The code uses `unsafe` blocks to call `unsafe` functions that have the documented invariant that the parameters passed in accurately describe the size of the array. However, this invariant is not necessarily held if an integer overflow occurs when evaluating the `assert` statements -- for example, by calling `transpose(&[], &mut [], 2, usize::MAX / 2 + 1)`. To answer the question of "where is the bug" -- by definitio…

I agree about what you write.. Also please note that I am not saying unsafe blocks are a bad idea. In fact, I think they are a great idea. But note that people run around saying "it is sufficient to audit unsafe blocks" but they really should say "audit unsafe and carefully analyze all logic elsewhere that may lead to a violation of their assumptions". You could argue "this is what they mean", but IMHO it is not quite the same thing and part of the usual exaggeration of the benefit of Rust safety, which I believe to be dangerously naive.

Re: Smart pointers for the kernel

#106

Post by [deleted] »

fshbbdssbbgdd wrote: post #96
kelnos wrote: post #8

Earlier quoted context omitted.

I don't think you're giving Rust enough credit here. For those projects that don't use any unsafe, we can say -- absent compiler bugs or type system unsoundness -- that there will be no memory leaks or data races or undefined behavior. That's useful! Very useful! For projects that do need unsafe, that unsafe code can be cordoned off into a corner where it can be made as small as possible, and can be audited. The rest…

Just to give an experience report as someone maintaining a 50k line rust codebase at work. I didn’t write this code and have only read parts of it. I am not a rust expert. I faced a really puzzling bug - basically errors coming out of an API that had nothing to do with the call site. After struggling to debug, I search for “unsafe” and looked at the 6 unsafe blocks in the project (totaling a few dozen lines of code),…

[deleted]

Re: Smart pointers for the kernel

#107

Post by biorach »

uecker wrote: post #104
lostdog wrote: post #97

Earlier quoted context omitted.

The most common bug in that type of code is mixing up x and y, or width and height somewhere in your loops, or maybe handling partial blocks. It's not really what Rust aims to protect against, though bounds checking is intended to be helpful here. I don't get the argumentshere. In practice, Rust lowers the risk of most of your codebase. Yeah, it doesn't handle every logic bug, but mostly you can code with confidence,…

The issue is a memory safety issue, which Rust aims to protect against. But I am not saying Rust is bad. My issue is the complete unreasonable exaggeration in propaganda from "C is completely dangerous and Rust is perfectly safe". And then you discuss and end up with "Rust does not protect against everything, but it still better", which could be the start of a reasonable discussion of how much better it actually is.

> C is completely dangerous and Rust is perfectly safe"

Nobody in this conversation said that.

If you're actually continuing an argument from somewhere else you should save everyone a lot of time and say so up front, not 10 comments in.

Re: Smart pointers for the kernel

#108

Post by pjmlp »

lertn wrote: post #71
kelnos wrote: post #8

Earlier quoted context omitted.

I don't think you're giving Rust enough credit here. For those projects that don't use any unsafe, we can say -- absent compiler bugs or type system unsoundness -- that there will be no memory leaks or data races or undefined behavior. That's useful! Very useful! For projects that do need unsafe, that unsafe code can be cordoned off into a corner where it can be made as small as possible, and can be audited. The rest…

With C you can take proven algorithms from CLRS and translate them directly without boilerplate. The same algorithms already become ugly/obfuscated in idiomatic C++. Looking at the macro in the LWN article, the approach of Rust of using wrappers and boxes and complex macros to emulate features appears to go into the same direction as C++. Still in 2024, gdb is far less useful for C++ than for C. C++ error messages ar…

That is a gdb problem, there are much better debuggers out there.

In C boilerplate is a called pre-processor magic.

Re: Smart pointers for the kernel

#109

Post by throwawaymaths »

kelnos wrote: post #8
foundry27 wrote: post #3

Earlier quoted context omitted.

Rust’s whole premise of guaranteed memory safety through compiletime checks has always been undermined when confronted with the reality that certain foundational operations must still be implemented using unsafe. Inevitably folks concede that lower level libraries will have these unsafe blocks and still expect higher level code to trust them, and at that point we’ve essentially recreated the core paradigm of C: trust…

I don't think you're giving Rust enough credit here. For those projects that don't use any unsafe, we can say -- absent compiler bugs or type system unsoundness -- that there will be no memory leaks or data races or undefined behavior. That's useful! Very useful! For projects that do need unsafe, that unsafe code can be cordoned off into a corner where it can be made as small as possible, and can be audited. The rest…

> Compilers and linters ... can help you here

Yeah. They can. You could even conceivably start a new c project with a "sufficiently right toolset" so that you get the same safety as rust...

Just, no one does.

Re: Smart pointers for the kernel

#110

Post by uecker »

biorach wrote: post #107
uecker wrote: post #104

Earlier quoted context omitted.

The issue is a memory safety issue, which Rust aims to protect against. But I am not saying Rust is bad. My issue is the complete unreasonable exaggeration in propaganda from "C is completely dangerous and Rust is perfectly safe". And then you discuss and end up with "Rust does not protect against everything, but it still better", which could be the start of a reasonable discussion of how much better it actually is.

> C is completely dangerous and Rust is perfectly safe" Nobody in this conversation said that. If you're actually continuing an argument from somewhere else you should save everyone a lot of time and say so up front, not 10 comments in.

The start of the thread was "The difference is every line of C can do something wrong while very few lines of Rust can." but this is an exaggeration of this kind.
Post reply on HN