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

321–330 of 395 posts

Re: Bugs Rust won't catch

#321

Post by slopinthebag »

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…

What an incredibly dishonest argument. Obviously "Well written C code" won't be riddled with CVE's by definition, the problem is that since programs written in C are littered with CVE's, it turns out it's really really difficult to write well written C, even for the best developers. With Rust, that entire class of problems is eliminated entirely.

Re: Bugs Rust won't catch

#322

Post by slopinthebag »

geocar wrote: post #202
sgt wrote: post #190

Earlier quoted context omitted.

"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…

100% it's the safer option. The software with the best security track record of all time is written in C.

The software with the worst security track record of all time is also written in C.

Re: Bugs Rust won't catch

#323

Post by 12_throw_away »

omcnoe wrote: post #94
alkonaut wrote: post #78

> What’s notable is that all of these bugs landed in a production Rust codebase, written by people who knew what they were doing So does this mean that neither did the original utils have any test harness, the process of rewriting them didn't start by creating one either? Sure there are many edge cases, but surely the OS and FS can just be abstracted away and you can verify that "rm .//" actually ends up doing what i…

My understanding is the uutils development process involved extensive testing against the behaviour of the original utilities, including preserving bugs.

If something as basic as "rm ./" is broken, the word "extensive" does not apply to whatever testing there was.

Re: Bugs Rust won't catch

#324

Post by pjmlp »

dapperdrake wrote: post #294
ericbarrett wrote: post #272

Earlier quoted context omitted.

Coreutils are not only used in interactive contexts. They are the primitives that make up the countless shell scripts which glue systems together. Any edge case will be encountered and the resulting poor performance will impact somebody, somewhere. Here's a related example of what happens when you change a shell primitive's behavior - even interactively. Back in the 2000s, Linux distributions started adding color out…

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.

Re: Bugs Rust won't catch

#325

Post by pjmlp »

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…

How many talks have you seen at USENIX that care about UNIX as desktop OS?

Exactly.

Re: Bugs Rust won't catch

#326

Post by pjmlp »

Joker_vD wrote: post #38
dapperdrake wrote: post #30

Earlier quoted context omitted.

Facetious reply: > However, GNU software tends to work very hard to avoid arbitrary limits [1].

Yes? The quote says "tends to", and you still can cd into that directory, albeit not in a single invocation. Windows has similar limitations [0], it's just that their MAX_PATH is just 260 so it's somewhat more noticeable... and IIRC the hard limit of 32 K for paths in non-negotiable. [0] https://learn.microsoft.com/en-us/windows/win32/fileio/maxim...

Not any longer unless you keep default enabled for backwards compatibility with older Windows software.

Re: Bugs Rust won't catch

#327

Post by comex »

dapperdrake wrote: post #296
Joker_vD wrote: post #38

Earlier quoted context omitted.

Yes? The quote says "tends to", and you still can cd into that directory, albeit not in a single invocation. Windows has similar limitations [0], it's just that their MAX_PATH is just 260 so it's somewhat more noticeable... and IIRC the hard limit of 32 K for paths in non-negotiable. [0] https://learn.microsoft.com/en-us/windows/win32/fileio/maxim...

Isn’t "cd" a unix syscall , because it changes the process's working directory? There was something written somewhere that it cannot be a unix utility for this very reason, but has to be a shell built-in. The syscall is a "single operation" from the point of a single-threaded process. What did I get wrong there? Side note: Missing bash$ man 1 cd ; Useful output bash$ help cd ;

Yes, it’s a shell builtin that makes the shell execute a chdir() syscall. Therefore it isn’t subject to argument length limits imposed by the kernel when executing processes. But it is still subject to path length limits imposed by the kernel’s implementation of chdir() itself. While the shell may be a GNU project (bash), the kernel generally is not (unless you are running Hurd), so this isn’t GNU’s fault per se.

However, the shell could theoretically chunk long cd arguments into multiple calls to chdir(), splitting on slashes. I believe this would be fully semantically correct: you are not losing any atomicity guarantees because the kernel doesn’t provide such guarantees in the first place for lookups involving multiple path components. I’m not surprised that bash doesn’t bother implementing this, and I don’t know if I’d call that an “arbitrary limitation” on bash’s part (as opposed to a lack of workaround for another component’s arbitrary limitation). But it would be possible.

Re: Bugs Rust won't catch

#328

Post by abbeyj »

> The Python one-liner is there because most modern shells refuse to create a non-UTF-8 filename for you.

Both `echo -ne 'weird\xffname\0' > list0` and `printf 'weird\xffname\0' > list0` seem to work fine for me on Linux. Is this macOS-specific?

Re: Bugs Rust won't catch

#329

Post by compass_copium »

bcjdjsndon wrote: post #256
jeroenhd wrote: post #53

Earlier quoted context omitted.

Nobody believes Rust programs are but free, though. Rust never promised that. It doesn't even promise memory safety, it only promises memory safety if you restrict yourself to safe APIs which simply isn't always possible.

The NSA believe it's a memory safe language.

Or... the NSA wants you to think the NSA believes that rust is a memory safe language.

Re: Bugs Rust won't catch

#330

Post by Joker_vD »

dapperdrake wrote: post #296
Joker_vD wrote: post #38

Earlier quoted context omitted.

Yes? The quote says "tends to", and you still can cd into that directory, albeit not in a single invocation. Windows has similar limitations [0], it's just that their MAX_PATH is just 260 so it's somewhat more noticeable... and IIRC the hard limit of 32 K for paths in non-negotiable. [0] https://learn.microsoft.com/en-us/windows/win32/fileio/maxim...

Isn’t "cd" a unix syscall , because it changes the process's working directory? There was something written somewhere that it cannot be a unix utility for this very reason, but has to be a shell built-in. The syscall is a "single operation" from the point of a single-threaded process. What did I get wrong there? Side note: Missing bash$ man 1 cd ; Useful output bash$ help cd ;

> What did I get wrong there?

Nothing; you just missed some other considerations. For instance, Linux generally follows POSIX. That's what the 2004 version has to say about chdir's errors:

    ERRORS
    The chdir() function shall fail if:

    ...
    [ENAMETOOLONG]
        The length of the path argument exceeds {PATH_MAX} or a pathname component is longer than {NAME_MAX}.
    ...

    The chdir() function may fail if:
    ...
    [ENAMETOOLONG]
        As a result of encountering a symbolic link in resolution of the path argument, the length of the substituted pathname string exceeded {PATH_MAX}.
However, the following versions of POSIX moved the "length of the path argument exceeds {PATH_MAX}" into the "optional error" part.
Post reply on HN