Readit News logoReadit News
chlorion commented on Effective Rust (2024)   lurklurk.org/effective-ru... · Posted by u/ibobev
milesrout · 6 months ago
Leaking memory is unsafe. It was considered unsafe for decades: a prime example of the sort of problem you get in C or C++ that you avoid with automatic memory management. Lots of real crashes, stability issues and performance issues have been caused by memory leaks over the years.

Rust initially advertised itself as preventing leaks, which makes sense as it is supposed to have the power of automatic memory management but without the runtime overhead.

Unfortunately, shortly before Rust's release it was discovered that there were some APIs that could cause memory corruption in the presence of memory leaks. The decision was made that memory leaks would be too complicated to fix before 1.0: it would have had to have been delayed. So the API in question was taken out and Rust people quietly memory-holed the idea that leak freedom has ever been considered part of memory safety.

chlorion · 6 months ago
The difference is that leaking is not UB, the worst case is an OOM situation, which at worst causes a crash, not a security exploit. Crashing is also considered to be safe in rust, panicking is common for example when something bad happens.
chlorion commented on Abusing C to implement JSON parsing with struct methods   xnacly.me/posts/2025/json... · Posted by u/ingve
uecker · 6 months ago
They will also do this in C++ or Rust. The only difference is that in Rust they will pretend it is ok because they wrapped it "unsafe", so if they mess up it is nobody's fault because it can not possible be a problem with Rust or the Rust programmer, so it was unavoidable fate.
chlorion · 6 months ago
What are you even talking about?

I've never saw anyone claim that doing UB in Rust is okay because its wrapped in an unsafe block?

If anything I've saw the exact opposite of this, cases of UB in libraries is considered a bug almost always, vs in C or C++ where "its the users fault for doing the thing wrong".

I notice you spreading an awful lot of bs about rust lately, not sure what the deal is but its pretty childish and lame, not to mention objectively wrong.

chlorion commented on Greg K-H: "Writing new code in Rust is a win for all of us"   lore.kernel.org/rust-for-... · Posted by u/mustache_kimono
whytevuhuni · 6 months ago
> My question is how likely can it be adopted in the kernel (likely high).

My guess is, it cannot. The way -fbounds-safety works, as far as I understand, is that it aborts the program in case of an out-of-bounds read or write. This is similar to a Rust panic.

Aborting or panicking the kernel is absolutely not a better alternative to simply allowing the read/write to happen, even if it results in a memory vulnerability.

Turning people's computer off whenever a driver stumbles on a bug is not acceptable. Most people cannot debug a kernel panic, and won't even have a way to see it.

Rust can side-step this with its `.get()` (which returns an Option, which can be converted to an error value), and with iterators, which often bypass the need for indexing in the first place.

Unfortunately, Rust can still panic in case of a normal indexing operation that does OOB access; my guess is that the index operation will quickly be fixed to be completely disallowed in the kernel as soon as the first such bug hits production servers and desktop PCs.

Alternatively, it might be changed to always do buf[i % buf.size()], so that it gives the wrong answer, but stays within bounds (making it similar to other logic errors, as opposed to a memory corruption error).

chlorion · 6 months ago
So out of bounds access leading to data loss and possible security vulnerability is better than crashing the kernel? That doesn't make sense to me.
chlorion commented on Backblaze seemingly does not support files greater than 1 TB   wadetregaskis.com/backbla... · Posted by u/amwolff
bifftastic · 7 months ago
Backblaze does not back up disk images. It's a documented limitation.

I just found this out the hard way.

chlorion · 7 months ago
A disk image is just a file though. Does it do some sort of analysis of files and block disk images somehow?

Maybe you mean that it doesnt do image-level backups by default?

chlorion commented on F-strings for C++26 proposal [pdf]   open-std.org/jtc1/sc22/wg... · Posted by u/HeliumHydride
rerdavies · 7 months ago
I'm wonder what this mysterious application is that is doing heavy formatting of strings but can't afford the overhead of a temporary string, and therefore requires horrifying and inscrutable and dangerous language extensions.
chlorion · 7 months ago
Being able to use string formatting without a heap is pretty cool.

Rusts string formatting machinery does not require any heap allocations at all, you can for example impl fmt::Write for a struct that writes directly to a serial console byte-by-byte with no allocations, and then you have access to all of rusts string formatting features available to print over a serial console!

I'm not sure about the horrifying and dangerous extensions part though, I'm not really a C++ expert so I don't know if there's a better way to do what they want to do.

chlorion commented on Ada's dependent types, and its types as a whole   nytpu.com/gemlog/2024-12-... · Posted by u/nytpu
nytpu · 8 months ago
It's FOSS and is actually included with GCC, but the toolchain is still a PITA to install just because no one (other than Debian and Arch Linux) bothers packaging it. I think Alire is supposed to make it easy to install but I haven't used it much: https://alire.ada.dev/

SPARK 2014 itself is the same too AFAIK, the problem is there's a lot of auxiliary static analysis tools and plugins that are gated behind AdaCore's sales wall (and of course they'd never deign to sell licenses affordable to individuals)

chlorion · 8 months ago
I'm pretty sure that gentoo also packages ada, but it doesn't get installed by default, as its behind a USE flag.
chlorion commented on Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches   verdagon.dev/grimoire/gri... · Posted by u/PotatoPancakes
nemaar · 8 months ago
> If you design a language that doesn't allow pointers to be shared across threads at all, then you wouldn't need a borrow checker.

Is that actually true? I'm pretty sure you need the borrow checker even for single threaded Rust to prevent use after frees.

chlorion · 8 months ago
Theres even more than just UAFs that you have to worry about in a single threaded context, but yes you are correct.

Here's a good post that talks about why shared mutability even in single threaded contexts is dangerous: https://manishearth.github.io/blog/2015/05/17/the-problem-wi...

chlorion commented on Show HN: A portable hash map in C   github.com/e-dant/salmagu... · Posted by u/e-dant
ivanjermakov · 9 months ago
What kind of disaster? Wouldn't OS security prevent userspace program do destructive things?
chlorion · 9 months ago
It depends.

You can corrupt memory in such a way that allows executing arbitrary code, in which you could do anything that the process has privilege to do, which is probably reading and writing files as the current user and a lot more.

chlorion commented on Emacs arbitrary code execution and how to avoid it   eshelyaron.com/posts/2024... · Posted by u/oskardrums
nine_k · 9 months ago
It looks like adding a defcustom that would disable macro expansion, and basically any attempts to eval the code being edited, should not be a lot of work, or at least doable. Disable it in your config, get a nerfed-down but shields-up elisp editing mode.

Am I missing anything here? E.g. should I expect pieces of C code that handle completion in elisp mode?

chlorion · 9 months ago
Would you mind explaining how you could do this?
chlorion commented on The two factions of C++   herecomesthemoon.net/2024... · Posted by u/cyclopeanutopia
bagxrvxpepzn · 9 months ago
To the people who work on C++ standards: I approve of the current C++ trajectory and please ignore all of the online noise about "the future of C++." To anyone that disagrees severely with the C++ trajectory as stated, please just consider another language, e.g. Rust. I don't want static lifetime checking in C++ and if you want static lifetime checking, please use Rust. I am not a government contractor, if you are a government contractor who must meet bureaucratic risk-averse government requirements, please use Rust. I have an existing development process that works for me and my customers, I have no significant demand for lifetime checking. If your development process is shiny and new and necessitates lifetime checking, then please use Rust. To Rust advocates, you can have the US government and big tech. You can even have Linux. Just leave my existing C++ process alone. It works and the trade offs we have chosen efficiently accomplish our goals.
chlorion · 9 months ago
Imagine an engineer in any other field acting like this.

"I don't want to install air bags and these shiny safety gadgets into my cars. We have been shipping cars without them for years and it works for us and our customers."

The problem is that it doesn't actually work as well as you think, and you are putting people at risk without realizing it.

u/chlorion

KarmaCake day676November 25, 2021View Original