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

371–380 of 395 posts

Re: Bugs Rust won't catch

#371

Post by testdelacc1 »

gmueckl wrote: post #286
testdelacc1 wrote: post #45

Earlier quoted context omitted.

Is it possible you’ve misunderstood what Rust promises? > It isn't possible to create a programing language that doesn't allow bugs to happen Yes, that’s true. No one doubts this. Except you seem to think that Rust promises no bugs at all? I don’t know where you got this impression from, but it is incorrect. Rust promises that certain kinds of bugs like use-after-free are much, much less likely. It eliminates some ki…

I understand the (narrow) hard guarantees that rust gives. But there there are people in the wider community who think that the guarantees are much, much broader. This is a pretty widespread misconception that should get be rectified.

Who are these people? Care to share examples?

Because all I see are examples of people claiming it happens all the time. Not the examples of it actually happening.

Re: Bugs Rust won't catch

#372

Post by Someone »

simiones wrote: post #247
jeroenhd wrote: post #178

Earlier quoted context omitted.

You have to choose something, and I'm glad they didn't go with the idiotic Go approach ("every path is a valid UTF-8 string" or we just garble the path at the standard library level"). You can usually abstract away platform weirdness at the implementation level, but programming on non-Unix environments it's more like programming against cygwin. A standard library for files and paths that lacks things like ACLs and lo…

> I'm glad they didn't go with the idiotic Go approach ("every path is a valid UTF-8 string" or we just garble the path at the standard library level") Can you expound a bit on this? I haven't been able to find any articles related to this kind of problem. It's also a bit surprising, given that Go specifically did not make the same choice as Rust to make strings be Unicode / UTF-8 (Go strings are just arrays of bytes…

> Go strings are just arrays of bytes,

https://go.dev/ref/spec#String_types: “A string value is a (possibly empty) sequence of bytes”

https://pkg.go.dev/strings@go1.26.2: “Package strings implements simple functions to manipulate UTF-8 encoded strings.”

So, yes, Go strings are just arrays of bytes in the language, but in the standard library, they’re supposed to be UTF-8 (the documentation isn’t immediately clear on how it handles non-UTF-8 strings).

I think this may be why the OP thinks the Go approach is “every path is a valid UTF-8 string”

Re: Bugs Rust won't catch

#373

Post by lelanthran »

kibwen wrote: post #140
adrian_b wrote: post #130

Earlier quoted context omitted.

Nobody disputes that Rust is one of the programming languages that prevent several classes of frequent bugs, which is a valuable feature when compared with C/C++, even if that is a very low bar. What many do not accept among the claims of the Rust fans is that rewriting a mature and very big codebase from another language into Rust is likely to reduce the number of bugs of that codebase. For some buggier codebases, a…

As other people have mentioned, the goal of uutils was not "let's reduce bugs in coreutils by rewriting it in Rust", it was "it's 2013 and here's a pre-1.0 language that looks neat and claims to be a credible replacement for C, let's test that hypothesis by porting coreutils, giving us an excuse to learn and play with a new language in the process". It seems worth emphasizing that its creation was neither ideological…

> It seems worth emphasizing that its creation was neither ideologically motivated nor part of some nefarious GPL-erasure scheme, it was just some people hacking on a codebase for fun.

What the motivation and intent was in 2013 is not necessarily relevant to what the motivation and intent is now.

It's even less relevant to what the effect is: the goal may be to replace $FOO software with $BAR software, but as things stand right now $FOO is "GPL" and $BAR is "MIT".

So, yeah, I don't want them to succeed at their primary goal, because that replaces pro-user software with pro-business software.

Re: Bugs Rust won't catch

#374

Post by tnova »

hu3 wrote: post #142
tnova wrote: post #110

Earlier quoted context omitted.

In my experience developing different types of applications in Rust, the claims of a "slow compiler" are overstated. Sub second iteration times are definitely a thing in Rust as well, unless you're adding a new dependency for the first time or building fresh.

Our experiences clearly differ then. And for others as well since it's a common complain. Countless time I have seen other people complain as well. There are articles about it even. Can't find the YouTube link now but recently a gamedev abandoned Rust due to compilation speed alone because iteration speed was paramount to their creative process. Handwaving isn't going to make it any better. And thinking Go/TS compila…

I think you could have left it at differing experiences and not gone further saying I'm handwaving anything. That doesn't seem productive.

I'm not saying that Rust compilation time is comparable to Go/TS, I'm saying the blanket claim that Rust iteration speed will be a bottleneck requires context.

I definitely agree with you that it is a complaint that is often repeated online, but that doesn't make it universally true. In my experience it's a claim that is often echoed without proper context.

Particularly in the case of AI Rust recompliation times in my experience have not been the dominant cost, but are instead overshadowed by inference time, the agent working through different approaches, etc.

Re: Bugs Rust won't catch

#375

Post by ozgrakkurt »

dlahoda wrote: post #359

Why differential fuzzing did not catch these bugs? https://github.com/uutils/coreutils/tree/main/fuzz/uufuzz

Looks like it doesn't really fuzz much.

https://github.com/uutils/coreutils/tree/main/fuzz/fuzz_targ...

Maybe these tests aren't even fuzz tests?

https://github.com/uutils/coreutils/blob/main/fuzz/fuzz_targ...

Even the tests that look ok are not that good in my opinion because there is no structure to it:

https://github.com/uutils/coreutils/blob/main/fuzz/fuzz_targ...

It should also try to generate mostly correct but slightly wrong things instead of just dumping random data into it.

Seems to also not expect some fuzz tests to even pass in the CI:

https://github.com/uutils/coreutils/blob/a07879b8ab2bb8fe5e0...

Re: Bugs Rust won't catch

#376

Post by ozgrakkurt »

satvikpendem wrote: post #195

Unrelated but also in the category of bugs Rust won't catch (natively), there are crates that allow C++ style contracts, or more generally, dependent typing and can be used to catch issues at compile time rather than runtime. I use this one, anodized. https://docs.rs/anodized/latest/anodized/

What do you think about the mental load and ergonomics this brings into the code? Also compilation time increase?

Re: Bugs Rust won't catch

#377

Post by pjmlp »

vablings wrote: post #331
pjmlp wrote: post #324

Earlier quoted context omitted.

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

For me it was the path of least resistance, I do use WebDAV more now since Copyparty supports it out of the box but I would be open to suggestions

Samba/SMB, Network protocols like WebDAV, S3, Docker, OneDrive,....

Re: Bugs Rust won't catch

#378

Post by thesuperbigfrog »

ragall wrote: post #355
dapperdrake wrote: post #307

Earlier quoted context omitted.

Welcome to building something new.

New things can be made optional and tested outside production, and should not be rolled out in an LTS edition.

>> should not be rolled out in an LTS edition.

The Rust coreutils were first rolled out in the previous release which was not LTS:

https://canonical.com/blog/canonical-releases-ubuntu-25-10-q...

Re: Bugs Rust won't catch

#379

Post by simiones »

jeroenhd wrote: post #250
simiones wrote: post #247

Earlier quoted context omitted.

> I'm glad they didn't go with the idiotic Go approach ("every path is a valid UTF-8 string" or we just garble the path at the standard library level") Can you expound a bit on this? I haven't been able to find any articles related to this kind of problem. It's also a bit surprising, given that Go specifically did not make the same choice as Rust to make strings be Unicode / UTF-8 (Go strings are just arrays of bytes…

Go's docs put it like this: Path names are UTF-8-encoded, unrooted, slash-separated sequences of path elements, like “x/y/z”. If you operate on a path that's a non-UTF-8 string, then Go will do... something to make the string work with UTF-8 when passed back to standard file methods, but it likely won't end up operating on the same file. Rust has OsStr to represent strings like paths, with a lossy/fallible conversion…

The `os` package, that is the main way everyone I've seen opens and reads files in Go, doesn't specify any restriction on its path syntax (except that it uses `string`, of course). I've tried using it on Linux with a file name that would be invalid UTF-8 and it works without any issues.

I for one hadn't even heard of the io/fs package that has the problems that you mention, and I don't remember ever seeing it used in an example. I've looked in a code base I help maintain, and the only uses I could find are related to some function type definitions that are used by filepath.WalkDir and filepath.Walk - and those functions explicitly document the fact that they don't use `io/fs` style paths when calling these functions - they don't even respect the path separator format:

  // WalkDir calls fn with paths that use the separator character appropriate
  // for the operating system. This is unlike [io/fs.WalkDir], which always
  // uses slash separated paths.
  func WalkDir(root string, fn fs.WalkDirFunc) error {
Where fs.WalkDirFunc is defined like this:

  type WalkDirFunc func(path string, d DirEntry, err error) error

Re: Bugs Rust won't catch

#380

Post by Arch-TK »

Joker_vD wrote: post #337
Arch-TK wrote: post #288

Earlier quoted context omitted.

musl has its own approach to this, it's called nscd It would have avoided the "running code as root" part, but it would still allow an attacker to control the result of the function call. I mean, the problem being solved here isn't exactly a bad problem to try to solve. You either permanently hard-code `/etc/passwd` as the user database, and `/etc/resolv.conf` as the source of DNS server information, or you allow the…

Obviously, if you tie the ability to handle those things to your filesystem layout, either by loading dynamic libraries from whatever is /usr/lib, or by reading /etc/whatever.conf, or even providing a whole virtual mount à la /proc, chroot'ing gives you both with the ability to override the system-wide policy for yourself (pretty reasonable for DNS lookups, kinda dubious for username lookups) and the opportunity to a…

What alternative solution do you actually propose here?

To clarify, the kernel doesn't (well, it gets complicated with things like NFSv4 but let's just ignore that since it doesn't really make or break my point) know anything about users or groups. It _only_ has the ability to manage some integers on a per-process basis and tie those into integers attached to files.

Assuming for now that we want to keep this like that, if you want to tie names to those numbers, you have to have some kind of database. If not by reading a config file, or by running some random code, or by some virtual file system (unless I misunderstood ?), what other options do you have?

Unix sockets have the same issue. There are abstract namespace sockets, but these don't exactly help solve the core problem, since now changing the network namespace can get you in the same trouble. This also covers any other kind of socket.

Even if the kernel did have the capacity to maintain this information, something would need to load it or back it, and that something could fall afoul of similar bugs.

> root should be restricted to executing/loading only a whitelist of executables/shared objects

It should already be possible to achieve this with IMA I believe?

> But then again, you'll need a allow_for_root(1) utility to maintain this whitelist, and people absolutely will call it in their setup scripts in all kinds of dubious manner.

You'd just keep the signing keys off the machine and either sign things off the host or sign them with presence detection and an HSM.

Post reply on HN