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

Cross-platform Rust rewrite of the GNU coreutils

github.com

Post reply on HN
Print view View original

481–490 of 498 posts

Re: Cross-platform Rust rewrite of the GNU coreutils

#481

Post by theseoafs »

jahewson wrote: post #294
jordigh wrote: post #276

Earlier quoted context omitted.

Are you a lawyer? Because other lawyers have told me otherwise. Would you happen to know of cases where your interpretation has been upheld?

Of course I can read something and not copy it. I can read a book and not copy it. I can listen to a song and not copy it. I can look at art and not copy it. And I can read source code and not copy it. It's not surprising that your lawyer implied otherwise, as its "best practice" to guard against every feasible risk, no matter how unlikely. Understand that your lawyer is protecting you against a hyper-zealous misinte…

Do you have any legal expertise whatsoever, or any basis for giving people legal advice?

Re: Cross-platform Rust rewrite of the GNU coreutils

#482

Post by tatterdemalion »

quotemstr wrote: post #467
tatterdemalion wrote: post #443

Earlier quoted context omitted.

Maybe avoid using judgmental language like calling a standard allocator that aborts on oom a "trap." The Rust team made conscious design choices in full awareness of the trade-offs. Moreover, Rust actually does have thread unwinding, and even the ability to catch an unwinding thread, so it is not true that the Rust standard library could not have unwound on oom. Rust's standard library just isn't designed for writing…

If Rust isn't suitable for C's niche, Rust's proponents should stop pitching Rust as a replacement for C. > The Rust team made conscious design choices in full awareness of the trade-offs I don't think that anyone who isn't already predisposed to avoid exceptions would consider the tradeoff the Rust people made to be the correct one.

This is absurd. Most C applications do not need to persist through OOM errors, and has people have repeatedly reiterated, it is totally possible to write a Rust program that persists through OOM errors.

Re: Cross-platform Rust rewrite of the GNU coreutils

#483

Post by pcwalton »

anp wrote: post #455
pcwalton wrote: post #435

Earlier quoted context omitted.

> One of the reasons golang is so successful is that there is very little magic in the syntax, and even when there is it's fairly easy to grok (an example would be the `go` keyword). Do you have a specific symbol you would like to change in Rust, and what would you like to change it to? The only example I've seen (in a child comment to yours) is effectively a complaint that Rust has lifetimes and Go doesn't, which is…

I'm definitely a Rust fanboy, but the single-quote syntax for lifetime annotations can be irritating. Several editors I've used automatically insert a second quote to match, and I am frequently unable to disable that behavior without losing all paired delimiter insertion (like for parentheses or braces). It's a minor quibble to be sure, but it's the only language symbol that bothers me when writing Rust. Not sure wha…

We had a big debate about it back in the day, and ' won as it's about as visually lightweight as you can get. I think the other characters you suggested would invite even more Perl comparisons.

Re: Cross-platform Rust rewrite of the GNU coreutils

#484

Post by pcwalton »

Dylan16807 wrote: post #452
pcwalton wrote: post #450

Earlier quoted context omitted.

> What do we do about the fact that undefined behavior actually makes it harder or impossible to write efficient code in some cases, like checking for integer overflow? This is a good example of why we should be moving away from C. :) Signed overflow being undefined is basically necessary due to a self-inflicted wound from 1978: the fact that "int" is the easiest thing to type for the loop index when iterating over a…

It just seems like such a waste to abandon C instead of smacking compiler/spec writers and getting them to specify behavior that was de-facto specified for decades. C should be writable by humans.

Totally disagree, and it's disappointing to see you suggest "smacking compiler writers" after this discussion which clearly established why the change you suggested does not work. This is not the fault of compiler writers like Chris, at all. They understand how the entire set of optimization passes fits together and do not throw in optimizations for no reason. They are doing what needs to be done to get performance out of a language written in 1978 with design mistakes. They are doing this because their customers demand it.

This entire discussion is predicated on the idea that undef values having a live range is something that actually prevents bugs, which I find extremely dubious. This is not like the "null dereference is UB" thing in the Linux kernel (which I also found to be overstated in importance, but it has caused at least one problem). I can't think of a single bug that this has caused, other than a compiler bug in Rust that was only exposed by people intentionally trying to write code that would break--that is, the bug had no practical effect. It strikes me as "friendly C lawyering" for little benefit.

Re: Cross-platform Rust rewrite of the GNU coreutils

#485

Post by msbarnett »

jeena wrote: post #63
mapleoin wrote: post #22

What are the licensing implications for this kind of work? I assume the authors used GNU coreutils as more than just inspiration. They probably read all the original code and reused some of the solutions (obviously ported to Rust). Shouldn't the derivative work still be covered by the GPL?

Just to give an example: https://github.com/uutils/coreutils/blob/master/src/whoami/p... looks suspically simmilar to: http://code.metager.de/source/xref/gnu/coreutils/src/whoami....

You know that whoami didn't originate with GNU, right?

The GNU coreutils are themselves rewrites of earlier BSD tools. The Rust version AND the GNU whoami.c both look similar to the BSD original https://github.com/weiss/original-bsd/blob/master/old/whoami.... Hell, the rust version is clearly a lot closer to the BSD original than to the GNU clone.

Honestly if you're going to have an opinion on this issue, you should try to educate yourself on all of the Unix that predates GNU.

Re: Cross-platform Rust rewrite of the GNU coreutils

#486

Post by Dylan16807 »

pcwalton wrote: post #484
Dylan16807 wrote: post #452

Earlier quoted context omitted.

It just seems like such a waste to abandon C instead of smacking compiler/spec writers and getting them to specify behavior that was de-facto specified for decades. C should be writable by humans.

Totally disagree, and it's disappointing to see you suggest "smacking compiler writers" after this discussion which clearly established why the change you suggested does not work. This is not the fault of compiler writers like Chris, at all. They understand how the entire set of optimization passes fits together and do not throw in optimizations for no reason. They are doing what needs to be done to get performance o…

>They are doing what needs to be done to get performance out of a language written in 1978 with design mistakes.

Then smack the spec writers for never removing undefined behavior. You don't have to smack both, but the two groups are working together to make C more dangerous every day.

>They are doing this because their customers demand it.

If you show a chart of how often the customer's code will stop working because of these optimizations, perhaps they will stop demanding it. But even if it's implemented, there should be a --reduce-undefined-optimization flag.

> I can't think of a single bug that this has caused

If it was defined, then the Debian RNG bug likely would not have happened.

If an undefined behavior is rare, that's a good reason to flatly remove it from the spec. If we could have 10 undefined behaviors instead of 200, the world would be better off. There are undefined behaviors you can hit during preprocessing, for crying out loud.

(Also even in the most extreme version, you wouldn't need to count it as live until the first access, and if that's the last access then there's no live range at all.)

Re: Cross-platform Rust rewrite of the GNU coreutils

#487

Post by lfowles »

goodplay wrote: post #458
oldmanjay wrote: post #419

Earlier quoted context omitted.

It is in the interests of a minority of programmers, themselves a tiny minority of the general public. Let's not get completely overblown about the stakes here.

The only reason I use the GPL is to safeguard the general public's rights to modify and distribute my software. If anything, I'd argue that releasing GPL software works against the author as it makes making money off it substantially more difficult.

The general public still retains the right to modify and distribute your software with a license such as MIT. Your software does not cease to exist once megacorp uses it for a product. The guarantee of GPL is that megacorp is now obligated to share their modifications (but practically, to go find another library or write their own).

Re: Cross-platform Rust rewrite of the GNU coreutils

#488

Post by pcwalton »

Dylan16807 wrote: post #486
pcwalton wrote: post #484

Earlier quoted context omitted.

Totally disagree, and it's disappointing to see you suggest "smacking compiler writers" after this discussion which clearly established why the change you suggested does not work. This is not the fault of compiler writers like Chris, at all. They understand how the entire set of optimization passes fits together and do not throw in optimizations for no reason. They are doing what needs to be done to get performance o…

>They are doing what needs to be done to get performance out of a language written in 1978 with design mistakes. Then smack the spec writers for never removing undefined behavior. You don't have to smack both, but the two groups are working together to make C more dangerous every day. >They are doing this because their customers demand it. If you show a chart of how often the customer's code will stop working because…

> If it was defined, then the Debian RNG bug likely would not have happened.

No. The Debian bug was not the result of a compiler optimization based on undefined behavior. It was due to OpenSSL doing something dodgy [1]. The compilers, being conservative, all declined to do any optimizations based on the undefined behavior. It was Valgrind that called OpenSSL out for the uninitialized use of memory. This is not a bug in Valgrind either! If the C standard defined live ranges for uninitialized values, then Valgrind would still be right to flag uses of uninitialized values, because they usually indicate bugs, and Valgrind is a bug finding tool. The Debian bug occurred because OpenSSL was doing something silly, Valgrind was doing its job properly pointing out that silly thing that OpenSSL was doing, and the fix was dangerously incorrect.

[1]: http://research.swtch.com/openssl

Re: Cross-platform Rust rewrite of the GNU coreutils

#489

Post by Dylan16807 »

pcwalton wrote: post #488
Dylan16807 wrote: post #486

Earlier quoted context omitted.

>They are doing what needs to be done to get performance out of a language written in 1978 with design mistakes. Then smack the spec writers for never removing undefined behavior. You don't have to smack both, but the two groups are working together to make C more dangerous every day. >They are doing this because their customers demand it. If you show a chart of how often the customer's code will stop working because…

> If it was defined, then the Debian RNG bug likely would not have happened. No. The Debian bug was not the result of a compiler optimization based on undefined behavior. It was due to OpenSSL doing something dodgy [1]. The compilers, being conservative, all declined to do any optimizations based on the undefined behavior. It was Valgrind that called OpenSSL out for the uninitialized use of memory. This is not a bug…

They got a report of dodgy code. Looking at the code, it was intentional but unimportant and also violated the C standard. So they removed it, and they removed it badly.

If it had been valid by the C standard, it is not unlikely that they would have kept it. Then there would have been no disaster. They would not have gotten confused about what was valid and what wasn't.

Extra entropy to mix in isn't that silly.

Edit: In other words, making "Is this code valid?" more complex to answer can have bad effects even in the absence of aggressive compilers.

Re: Cross-platform Rust rewrite of the GNU coreutils

#490

Post by pcwalton »

Dylan16807 wrote: post #489
pcwalton wrote: post #488

Earlier quoted context omitted.

> If it was defined, then the Debian RNG bug likely would not have happened. No. The Debian bug was not the result of a compiler optimization based on undefined behavior. It was due to OpenSSL doing something dodgy [1]. The compilers, being conservative, all declined to do any optimizations based on the undefined behavior. It was Valgrind that called OpenSSL out for the uninitialized use of memory. This is not a bug…

They got a report of dodgy code. Looking at the code, it was intentional but unimportant and also violated the C standard. So they removed it, and they removed it badly. If it had been valid by the C standard, it is not unlikely that they would have kept it. Then there would have been no disaster. They would not have gotten confused about what was valid and what wasn't. Extra entropy to mix in isn't that silly. Edit:…

No, this is again completely incorrect. This had nothing whatsoever to do with the C standard. This is Valgrind's issue. Valgrind does not care about what the C standard says. Valgrind is a bug-finding tool and as such can make its own rules.

Once again, if the C standard were to change to allow uninitialized variables to have live ranges, Valgrind would not just "git rm -rf memcheck; git commit". That is because Valgrind is a tool that is designed to check for uninitialized memory. It did its job properly. It is not designed to check for undefined behavior according to the C standard.

You seem to be determined to lay the blame for every problem at some combination of C compiler authors and C spec writers, regardless of whether the problem actually is theirs.

Post reply on HN