Rust-Written Replacement To GNU Coreutils Progressing, Some Binaries Now Faster

[MadCatX]

If it was well defined then it wouldn't have so much undefined behavior. Why can you use some variables before they are initialized? That is a broken language feature.

At least some of this stuff is allowed because it was expected to interact directly with hardware in C programs. Volatile variables, for instance, can be set by some HW device instead of the program. You can also set variables or return values from inline assembly instead of C. This all made sense when you programmed your C64 in 1983 but is mostly obsolete in 2022.

[sdack]

... You are assuming that anyone who doesn't agree with you doesn't "see" it. ...

No, only you are assuming. I am talking directly to specific people, just like I am talking to you now.

Simplicity is what allowed C to prevail. It allowed having different compilers from competing makers and different versions of the language over time, and it still manages to produce runnable code. C has always been diplomatic with its environment. You will never have this with Rust. Rust alienates its environment as a principle of its existence.

[Raka555]

At least some of this stuff is allowed because it was expected to interact directly with hardware in C programs. Volatile variables, for instance, can be set by some HW device instead of the program. You can also set variables or return values from inline assembly instead of C. This all made sense when you programmed your C64 in 1983 but is mostly obsolete in 2022.

Until you want to write something that runs on a micro controller or bare metal RPI (or similar device)
And we programmed our C64's in assembly back then, not C.

[soulsource]

At least some of this stuff is allowed because it was expected to interact directly with hardware in C programs. Volatile variables, for instance, can be set by some HW device instead of the program. You can also set variables or return values from inline assembly instead of C. This all made sense when you programmed your C64 in 1983 but is mostly obsolete in 2022.

It wasn't that reasonable back then either. It's not like Rust wouldn't allow you to leave variables uninitialized or to have the same behaviour as C's volatile keyword. It's just not the default, because it's far more common that one forgets to initialize a variable although one wanted to, than that one needs an uninitialized value.
There's another thing at play here, btw.: While Rust is a multi-paradigm language, it's much closer to functional syntax than C(++) is.

[wswartzendruber]

So Rust it is just the excuse to erase the GPL from the "GNU Coreutils" and to leave just "Coreutils". Genius!

We *want* new Coreutils to be MIT licensed because we want as many people using them as possible. Hopefully, macOS does something with them.

Security wise, everyone is better off the more we can get the C programming language *off* of store shelves.

[sdack]

... it's far more common that one forgets to initialize a variable although one wanted to, than that one needs an uninitialized value. ...

Forcing programmers to initialize variables is not the same as forcing them to program correctly. It only forces them to assign values to their variables and it often ends being 0. The real problem is that when a programmer forgets to initialize a variable before using it, then it really means that he forgot what value it has by the time he is using it. It there matters little whether the variable was initialized with a 0, 1, has a random value, or is uninitialized.

What does help is to warn programmers of uninitialized uses, because by some chance might they look at their code again and they might spot the problem, which can be a completely different one, i.e. a misspelled name such as using i instead of n. However, forcing programmers to always initialize their variables only removes the chance for them to get this warning. They will simply initialize all variables, and as a result, will the compiler throw fewer warnings and produce seemingly working code, but it may not actually work correctly and the programmer has no clue as to why.

[Volta]

Linux sucks.

Linux killed your POS OS? Good!

[Siuoq]

Unless there is proof of GNU Coreutils actually being unsafe is the project a waste of time. It would be better to improve GNU Coreutils directly than to have yet another clone or fork of something with an unproven claim on it being supposedly safer without ever providing hard evidence.

Well yes, but actually no. I think you can consider C codes as technical debt. There is no reason for a piece of code to be in C, it just causes it hard to maintain, change, debug, possibly risky, etc. Even if it's not a "debt" since there were no better option available when they first created Coreutils. "Rewrite It In Rust" is just the logical way of doing things. (Although. A rewrite will be more buggy for sure for a while, also easier modification will cause shorter lifespans, and compatibility issues.)

[soulsource]

Forcing programmers to initialize variables is not the same as forcing them to program correctly. It only forces them to assign values to their variables and it often ends being 0. The real problem is that when a programmer forgets to initialize a variable before using it, then it really means that he forgot what value it has by the time he is using it. It there matters little whether the variable was initialized with a 0, 1, has a random value, or is uninitialized.

That's why I mentioned that Rust is closer to functional programming languages. The term "variable" is actually a misnomer in that context, as in idiomatic Rust almost all values are immutable, and their final value is known at the point of declaration.
This is very similar to the concept known as "const correctness" in C/C++, with the main difference being that it's the default behaviour in Rust.

What does help is to warn programmers of uninitialized uses, because by some chance might they look at their code again and they might spot the problem, which can be a completely different one, i.e. a misspelled name such as using i instead of n. However, forcing programmers to always initialize their variables only removes the chance for them to get this warning. They will simply initialize all variables, and as a result, will the compiler throw fewer warnings and produce seemingly working code, but it may not actually work correctly and the programmer has no clue as to why.

The warning would only be shown if one of the values were not initialized. The equivalent situation in Rust (or const-correct C/C++) would be that one variable is not declared yet, and will also yield a compiler error.

[F.Ultra]

Yeah, it's in the standard since C99, but who uses it? It's incredible insecure, because the programmer has to say: "I promise here is no pointer aliasing". How often do you see the restrict keyword in function parameters? I have never seen them in the wild. So in theory C has the feature, but almost no one uses it, because if the condition is violated, you have undefined behaviour.

It has been in the standard since day one, however most compilers only implemented strict aliasing when C99 was in the works. Don't confuse this with the "restrict" keyword where you can declare pointers of the same type as not being allowed to alias. That said the benefits of restrict is mostly academic, the compiler does a code analysis already to determine of the pointers really do alias or not and for 99% of cases (or something around that number) the compiler makes the correct guess. I've never seen any benchmarks where restrict makes any difference outside of error bars.

No the reason why these new coreutils in Rust is faster than the old ones in C is that they use new algorithms and that the old GNU utilities where written to run on systems with 4kb of RAM.