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

Bugs Rust won't catch

corrode.dev

Post reply on HN
Print view View original

341–350 of 395 posts

Re: Bugs Rust won't catch

#341

Post by kibwen »

nixpulvis wrote: post #252

> These are noisy in test code where panicking on bad data is exactly what you want. The cleanest way to scope them to non-test code is to put #![cfg_attr(test, allow(clippy::unwrap_used, clippy::expect_used, clippy::panic, clippy::indexing_slicing, clippy::arithmetic_side_effects))] at the top of each crate root, or to gate #[allow(...)] on the individual #[cfg(test)] modules. Surely there's a better way.

Clippy doesn't even run on unit tests by default. Honestly it doesn't seem very useful to have it do so for ordinary development, but maybe you'd want to run Clippy on your unit tests in CI just to be extra safe, in which case you could encode those allowed lints in the line of your CI config where you run `cargo clippy`, e.g. `cargo clippy -- -A unwrap_used -A expect_used -A panic -A indexing_slicing -A arithmetic_side_effects`, if you really didn't want to have them in the source for whatever reason.

Re: Bugs Rust won't catch

#342

Post by magicalhippo »

kibwen wrote: post #267
ChrisSD wrote: post #225

Earlier quoted context omitted.

> WinAPI access for ACLs was added in Windows 10 I'm not sure which docs you mean but that's not true. The NT kernel has used ACLs long before rust was invented. But it's indeed true that rust adds platform-specific methods based on demand. The trouble with ACLs is it means either creating a large API surface in the standard library to handle them or else presenting a simple interface but having to manage raw pointer…

> I'm not sure which docs you mean I was looking at these: https://learn.microsoft.com/en-us/windows/security/identity-... > the winapi crate has been effectively unmaintained Shows how much of a Windows dev I am. :P

You'd want to be looking at these[1] instead, especially SetFileSecurity[2].

As noted, the "minimum supported" version means exactly that, and does not reflect when the API function was introduced.

[1]: https://learn.microsoft.com/en-us/windows/win32/secauthz/low...

[2]: https://learn.microsoft.com/en-us/windows/win32/api/winbase/...

Re: Bugs Rust won't catch

#343

Post by throw7 »

The "kill -1" is hilarious. I wouldn't use ubuntu for production for quite awhile while things shake out or, probably, never (since i don't use ubuntu).

Re: Bugs Rust won't catch

#344

Post by Pay08 »

timcobb wrote: post #73
antonvs wrote: post #65

Earlier quoted context omitted.

I love Rust, but I wonder if this is an example of the idea that its excellent type system can lull some people into a false sense of security. Particularly when interfacing to low-level code like kernel APIs, which are basically minefields inadvertently designed to trick the unwary, the Rust guarantees are undermined. The extent of this may not be immediately obvious to everyone.

This seems to be the case, yes. Before reading this post I was a lot more open minded about the "rewrite it in Rust" scene but now I'm just kind of in a horrorpit wondering whether I'll be stuck on macOS forever :(.

I don't think that is the case. I think the people that wrote this are simply bad programmers. Some of these issues are so obvious that if you've been doing any amount of programming, you should be able to anticipate them, whether you're writing C, Rust, or Java.

Re: Bugs Rust won't catch

#345

Post by estebank »

kibwen wrote: post #341
nixpulvis wrote: post #252

> These are noisy in test code where panicking on bad data is exactly what you want. The cleanest way to scope them to non-test code is to put #![cfg_attr(test, allow(clippy::unwrap_used, clippy::expect_used, clippy::panic, clippy::indexing_slicing, clippy::arithmetic_side_effects))] at the top of each crate root, or to gate #[allow(...)] on the individual #[cfg(test)] modules. Surely there's a better way.

Clippy doesn't even run on unit tests by default. Honestly it doesn't seem very useful to have it do so for ordinary development, but maybe you'd want to run Clippy on your unit tests in CI just to be extra safe, in which case you could encode those allowed lints in the line of your CI config where you run `cargo clippy`, e.g. `cargo clippy -- -A unwrap_used -A expect_used -A panic -A indexing_slicing -A arithmetic_s…

Delaying the run of clippy until CI would be annoying, because then you'd get a build failure for something that was preventable and could have been quickly addresses during development before pushing. Just feels like a pebble in your shoe.

Re: Bugs Rust won't catch

#346

Post by Pay08 »

sgt wrote: post #190
slopinthebag wrote: post #18

I find it interesting how people will criticise Rust for not preventing all bugs, when the alternative languages don't prevent those same bugs nor the bugs rust does catch . If you're comparing Rust to a perfect language that doesn't exist, you should probably also compare your alternative to that perfect language as well right? I'd be interested in a comparison with the amount of bugs and CVE's in GNU coreutils at t…

"The alternative languages" - in this case you're talking about C, 99% of the time. So let's talk about that. Well written C code, especially for the purpose of writing and continuing to maintain mature GNU coreutils, is not a big risk in terms of CVE. Between having an inexperienced Rust developer and an extremely experienced C developer (who's been through all the motions), I'd say the latter is likely the safer op…

> "The alternative languages" - in this case you're talking about C, 99% of the time.

And that's part of the problem. There's no excuse beyond maybe platform support for starting a brand new project in C, when C++ exists.

Re: Bugs Rust won't catch

#347

Post by VorpalWay »

pjmlp wrote: post #324
dapperdrake wrote: post #294

Earlier quoted context omitted.

In short, NFS has a terrible data model and only pretends to be a file system.

Hence why even on UNIX people moved on from NFS, but on Linux it keeps being the remote filesystem many reach for.

NFS is more annoying on Linux than just using Samba though, at least for the NAS use case. With Samba on my server I can just browse to it in KDE's file manager Dolphin, and samba configuration is a relatively straight forward ini style file on the server. A pair of ports also need to be opened in the host firewall.

Contrast that with NFS, which last I looked needed several config files, matching account IDs between hosts, mounting as root, and would hang processes if connection was lost. At least I hear rpcbind is gone these days.

I don't think anyone sane uses NFS on Linux either these days. And it is rather funny that the protocol Microsoft invented is what stuck and became practical between Linux hosts.

Re: Bugs Rust won't catch

#348

Post by Pay08 »

kibwen wrote: post #208
bayindirh wrote: post #158

> This is the largest cluster of bugs in the audit. It’s also the reason cp, mv, and rm are still GNU in Ubuntu 26.04 LTS. :( This is what grinds my gears. Why all the hate against GNU? Honestly, this is why I don't learn Rust, and why I didn't bother to read the rest of the article.

Rust does not hate GNU, and I'm not sure why anyone would have that misconception. It would be like saying that C hates GNU because the BSDs aren't GNU. The fact that there is less GNU-licensed Rust software than MIT-licensed Rust software is attributable to the simple fact that, in general, GNU has been ceding ground to MIT for more than 20 years.

Nor does the parent comment say that "Rust" hates GNU. A language can't hate anything for that matter.

Re: Bugs Rust won't catch

#349

Post by ragall »

jorvi wrote: post #179
awesome_dude wrote: post #114

Earlier quoted context omitted.

> Question 2: > Does throughput really matter more than latency in everyday application? IME as a user, hell yes Getting a video I don't mind if it buffers a moment, but once it starts I need all of that data moving to my player as quickly as possible OTOH if there's no wait, but the data is restricted (the amount coming to my player is less than the player needs to fully render the images), the video is "unwatchable…

Hell no. Linux desktop (and the kernel) felt awful for such a long time because everyone was optimizing for server and workstation workloads. Its the reason CachyOS (and before that Linux Zen and.. Licorix?) are a thing. For good UX, you heavily prioritize latency over throughput. No one cares if copying a file stalls for a moment or takes 2 seconds longer if that ensures no hitches in alt tabbing, scrolling or mouse…

When Kon Colivas introduced a scheduler optimized for desktop latency, about 15 years ago, the amount of abuse he got from Linux developers was astonishing, and he ended up quitting for good. I remember compiling it on my laptop and noticing how it made a huge improvement in the useability of X and desktop environment.

Re: Bugs Rust won't catch

#350

Post by duped »

dapperdrake wrote: post #293
duped wrote: post #260

Earlier quoted context omitted.

Just want to point out that race conditions are a correctness problem, not a performance problem.

Accurate a.k.a. "correct" implementation of ACID needs a single (central) source of truth and temporal serializability (or something close to that). In practice this always "impacts" performance. If I understand it correctly, then in physics this is called an event horizon.

Not necessarily. Most race conditions violate the `A` in ACID, but the finicky thing about atomicity is that N > 1 sequential actions that in and of themselves are atomic violates atomicity. So any atomic store is possible to misuse if you can compose multiple atomic operations on it.

In addition ACID isn't always provided by the floor beneath your programs but by designing the programs on top to uphold it and/or not require it, allowing you to relax the constraints from your lower level interfaces for performance reasons.

Post reply on HN