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

The Rust Libs Blitz

blog.rust-lang.org

Post reply on HN
Print view View original

31–40 of 125 posts

Re: The Rust Libs Blitz

#31

Post by Animats »

Manishearth wrote: post #28
eximius wrote: post #23

Earlier quoted context omitted.

In Rust, 'unsafe code' is really 'partially compiler check exempt'. It does not mean the code is unsafe. You can manually verify the 'unsafe' parts. It is very unfortunately named.

Yes, but the few exemptions means that you can effectively do basically anything. If you needed unsafe {} for something that block definitely needs more scrutiny and if possible should be avoided.

Right. That's the road to buffer overflow exploits.

The most recent CERT advisory reporting a buffer overflow exploit was April 17th, 2017.[1] About one per week is reported, year after year. Others not reported are probably being exploited. Rust can stop that, but one "unsafe" declaration can break Rust's safety.

Hash maps need to be 100% safe code. They're complicated, and involve elaborate calculations that output subscripts.

[1] http://www.kb.cert.org/vuls/id/676632

Re: The Rust Libs Blitz

#33

Post by Manishearth »

Animats wrote: post #29
Manishearth wrote: post #17

Earlier quoted context omitted.

https://github.com/bluss/ordermap is 100% safe rust and pretty fast I believe the stdlib one could be refactored, but I'm not sure. There are a lot of optimizations in that one. IMO "no unsafe code" is a stretch. "no unnecessary unsafe code" is what it should be.

That "ordermap" is nice. Could that replace std::collections::hash_map as the main supported map crate? It imports std::collections::hash_map, which has unsafe code, but only for RandomState, which does not. If RandomState were pulled out of hash_map and moved to a crate with no unsafe code, that dependency could be removed and it would be safe crates all the way down. IMO "no unsafe code" is a stretch. "no unnecessa…

> Could that replace std::collections::hash_map as the main supported map crate?

No, it is more specialized for certain kinds of loads.

> It imports std::collections::hash_map, which has unsafe code, but only for RandomState, which does not. If RandomState were pulled out of hash_map and moved to a crate with no unsafe code, that dependency could be removed and it would be safe crates all the way down.

That's a very vacuous distinction.

This is all in the same crate (std) anyway, it's just a different module.

> The author of the code doesn't get to determine "unnecessary".

The auditors (proposed in this blog post) do.

I've audited unsafe in the past to ensure our dependencies are fine, there are some pretty reasonable ways to define "unnecessary" here.

Re: The Rust Libs Blitz

#34

Post by hyperpape »

eximius wrote: post #23
Animats wrote: post #9

Does the "Rust standard of quality" for these crucial crates include "no unsafe code"? "Vec" currently needs unsafe code, because Rust doesn't have the expressive power to talk about a partially initialized array. Everything else with unsafe code is an optimization. Often a premature one. Maps should be built on "Vec", for example.

In Rust, 'unsafe code' is really 'partially compiler check exempt'. It does not mean the code is unsafe. You can manually verify the 'unsafe' parts. It is very unfortunately named.

It's unsafe in roughly the same way that Rust developers call C and C++ unsafe, right? The advantage is that it's a special, relatively uncommon mode, and it's explicitly marked. But I don't think you can minimize the reality that it's unsafe without also minimizing one of the major selling points of the language.

Re: The Rust Libs Blitz

#35

Post by Manishearth »

Animats wrote: post #31
Manishearth wrote: post #28

Earlier quoted context omitted.

Yes, but the few exemptions means that you can effectively do basically anything. If you needed unsafe {} for something that block definitely needs more scrutiny and if possible should be avoided.

Right. That's the road to buffer overflow exploits. The most recent CERT advisory reporting a buffer overflow exploit was April 17th, 2017.[1] About one per week is reported, year after year. Others not reported are probably being exploited. Rust can stop that, but one "unsafe" declaration can break Rust's safety. Hash maps need to be 100% safe code. They're complicated, and involve elaborate calculations that output…

It's pretty easy to audit a couple lines of unsafe in a library.

It is not easy to do the same with a C library where it's basically prone to overflow issues everywhere.

These are vastly different issues. Yes, we should totally be strict on unsafe code. No, it is not the end of the world when the stdlib hashmap uses unsafe code. Unsafe is designed exactly for this purpose, dealing with the innards of safe abstractions. It does it well, and the hashmap code is pretty ok here.

(Sure, if it has a design which could be done in safe Rust, it should, but I suspect with the way the robin hood stuff works it might not. this has been on my list of things to do when I get more time, primarily to just learn about the hashmap impl, but also to improve it if possible)

Re: The Rust Libs Blitz

#36

Post by pcwalton »

Animats wrote: post #9

Does the "Rust standard of quality" for these crucial crates include "no unsafe code"? "Vec" currently needs unsafe code, because Rust doesn't have the expressive power to talk about a partially initialized array. Everything else with unsafe code is an optimization. Often a premature one. Maps should be built on "Vec", for example.

> Everything else with unsafe code is an optimization.

You need unsafe code to invoke a syscall. Doing I/O is not an "optimization".

Re: The Rust Libs Blitz

#37

Post by Manishearth »

ronjouch wrote: post #27
dtolnay wrote: post #8

Earlier quoted context omitted.

Yes! The statically checkable ones will be checked by rustc or Clippy. Though some of the guidelines are at a higher level than what those would be able to check. For example: rustc wouldn't be able to tell whether a particular one of your traits would be valuable to make accessible as a trait object.

Beginner question: what would make a crate non -statically-checkable?

A guideline like "your tests should test all major functionalities of an API" can't be statically checked for example.

It's not about the crate being non checkable, it's about the check being something that needs a human to look at.

Re: The Rust Libs Blitz

#38

Post by stcredzero »

There’s a countervailing mindset which, in its harshest terms, says “the standard library is where code goes to die”

This can be addressed in a language with sufficient annotation and good parser tools. In some future language, there should be a unification between the version control, the de-facto codesharing site, language/library versions, and syntax-driven tools to automatically rewrite code.

It should be possible to "publish" a language and its libraries such that any breaking changes will automatically be updated when you switch library versions. (This should also be applicable to Entity-Relation diagrams and Object-Relational mappings -- those can be treated as a versioned library.)

Re: The Rust Libs Blitz

#40

Post by [deleted] »

z1mm32m4n wrote: post #14

I really love seeing articles like this come out about Rust. It's language design the way it should be: incorporating the cutting edge ideas from academia while still striving to cater to beginners; drawing on the strengths of other languages communities to build out good library and solutions to package management; designing everything in the open, and constantly seeking feedback from their users. It's a great blend…

[deleted]
Post reply on HN