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

Rust: 128 bit integers preparing to be released

github.com

Post reply on HN
Print view View original

41–50 of 173 posts

Re: Rust: 128 bit integers preparing to be released

#41

Post by steveklabnik »

cyphreak wrote: post #27
steveklabnik wrote: post #10

Earlier quoted context omitted.

> After the quadratic hashes Reference: http://accidentallyquadratic.tumblr.com/post/153545455987/ru... (bugs happen, fix is in the queue, life goes on) > rumored memory issues Rumors are just rumors. If you (or anyone else) has more than FUD here, please email https://www.rust-lang.org/security.html .

Why would they? Do you have any idea how much money a vuln like that would be worth? You've threatened to kill people on twitter and you think someone would turn something like that over to the team out of charity? You're delusional. I've never seen a million-dollar exploit, but DAMN if this wouldn't be close.

I can't believe that I (apparently) have to say this, but I

1. Would certainly not threaten to kill anyone on twitter.

2. Would certainly not threaten to kill someone for reporting a security vulnerability in Rust.

In fact, as I said above, I would prefer that people report them, so that everyone using Rust can be safe from vulnerabilities.

Re: Rust: 128 bit integers preparing to be released

#42

Post by rickycook »

Gankro wrote: post #36
drfuchs wrote: post #32

Earlier quoted context omitted.

But you do want to compare GUIDs. And hash them, which can involve shifting, adding, xor'ing, multiplying, remaindering, etc.

If you can't already hash/compare an array of bytes, something terrible has happened with your language design.

well, you can already do operations on 128bit of data that represents and int as well, but that's a kind of silly thing to say because higher level abstractions are just about making things easier. so now you can do it in 1 operation rather than several; if that's all you gain, then it's still worth it

Re: Rust: 128 bit integers preparing to be released

#43

Post by steveklabnik »

kevhito wrote: post #39
steveklabnik wrote: post #23

Earlier quoted context omitted.

128 bit floats were removed years ago (June of 2014), here's the meeting notes from the time: https://github.com/rust-lang/meeting-minutes/blob/master/wee... (as with all old Rust stuff, please remember that details very much might have changed between then and now.) In other words, they weren't removed because we fundamentally didn't want them. They were removed because of maintainability, usability, and usefulness…

I wasn't able to find any real justification beyond (a) one vague mention of "some algorithms... such as certain cryptographic algorithms" and (b) the fact that clang supports it. Can you point to something more specific? Justification (b) in particular smells bad to me.

I wasn't involved in the discussion really, so I don't have anything off-hand.

I can see why (b) might smell a bit bad, but think of it this way: we share a backend with clang, and so if they think support is mature enough to ship, then that's a very positive sign.

Re: Rust: 128 bit integers preparing to be released

#44

Post by steveklabnik »

dbaupp wrote: post #37
XorNot wrote: post #33

Earlier quoted context omitted.

Avoiding pointers to arrays is nice. This is the big annoyance in Golang with it's net.IP type - it's `type IP []byte`, which means you can write ip1 == ip2 and you can't pass by value easily, nor use it as a map key. I've ended up inventing my own type for that a lot of the time as a struct wit static fields, since those you can copy around and do 1:1 comparisons. Though to be honest I'd be super happy if there was…

Rust offers non-allocating fixed-sized arrays, so a GUID could be a (wrapper around) [u8; 16] and an IPv6 address could be [u16; 8].

That's exactly how the UUID crate implements them: https://github.com/rust-lang-nursery/uuid/blob/master/src/li...

Re: Rust: 128 bit integers preparing to be released

#45

Post by drfuchs »

andars wrote: post #8

In case anyone else is interested in reading it, the relevant RFC is here: https://github.com/rust-lang/rfcs/blob/master/text/1504-int1...

The RFC doesn't seem to mention anything about the atomicity (or lack thereof) of loads and stores of variables of the 128-bit types. From the discussion, it seems that on a number of current architectures, they're not going to be atomic.

Does this cause any problems in the Rust view of the world? Will there be unanticipated issues for developers who have been getting along just fine so far unknowingly assuming that all operations are atomic, which they have been just by virtue of how the hardware works?

Re: Rust: 128 bit integers preparing to be released

#46

Post by steveklabnik »

drfuchs wrote: post #45
andars wrote: post #8

In case anyone else is interested in reading it, the relevant RFC is here: https://github.com/rust-lang/rfcs/blob/master/text/1504-int1...

The RFC doesn't seem to mention anything about the atomicity (or lack thereof) of loads and stores of variables of the 128-bit types. From the discussion, it seems that on a number of current architectures, they're not going to be atomic. Does this cause any problems in the Rust view of the world? Will there be unanticipated issues for developers who have been getting along just fine so far unknowingly assuming that…

Rust has separate atomic types for doing atomic operations, so currently, none of them are.

So, if you wanted an atomic type, you'd find it here: https://doc.rust-lang.org/stable/std/sync/atomic/index.html

In other words, no, it shouldn't be a problem, at least in my understanding.

Re: Rust: 128 bit integers preparing to be released

#47

Post by drfuchs »

Gankro wrote: post #36
drfuchs wrote: post #32

Earlier quoted context omitted.

But you do want to compare GUIDs. And hash them, which can involve shifting, adding, xor'ing, multiplying, remaindering, etc.

If you can't already hash/compare an array of bytes, something terrible has happened with your language design.

Not in a way that complies into one or two machine instructions. So, your array code is an order of magnitude or two too slow. Never mind having to write it at all.

Added: I'm talking about implementing specific, optimized hash functions on 128-bit values (e.g. GUIDs, IPv6 addresses), and not generic hash functions that can take any length input (although many of them speed up linearly in the size of int that gets used internally).

Re: Rust: 128 bit integers preparing to be released

#48

Post by kevhito »

kevhito wrote: post #39
steveklabnik wrote: post #23

Earlier quoted context omitted.

128 bit floats were removed years ago (June of 2014), here's the meeting notes from the time: https://github.com/rust-lang/meeting-minutes/blob/master/wee... (as with all old Rust stuff, please remember that details very much might have changed between then and now.) In other words, they weren't removed because we fundamentally didn't want them. They were removed because of maintainability, usability, and usefulness…

I wasn't able to find any real justification beyond (a) one vague mention of "some algorithms... such as certain cryptographic algorithms" and (b) the fact that clang supports it. Can you point to something more specific? Justification (b) in particular smells bad to me.

Oh, just found this:

> The Duration type could be simplified with this: instead of using a u64 for seconds with a seperate u32 for nanoseconds, it could just be a single u128/i128 count of nanoseconds.

Of course, just a single u64 at ns precision would get you 500+ years of range. But ok.

Re: Rust: 128 bit integers preparing to be released

#50

Post by barsonme »

dbaupp wrote: post #37
XorNot wrote: post #33

Earlier quoted context omitted.

Avoiding pointers to arrays is nice. This is the big annoyance in Golang with it's net.IP type - it's `type IP []byte`, which means you can write ip1 == ip2 and you can't pass by value easily, nor use it as a map key. I've ended up inventing my own type for that a lot of the time as a struct wit static fields, since those you can copy around and do 1:1 comparisons. Though to be honest I'd be super happy if there was…

Rust offers non-allocating fixed-sized arrays, so a GUID could be a (wrapper around) [u8; 16] and an IPv6 address could be [u16; 8].

So does Go, so a net.IP could be [16]byte or [4]byte, but I'm sure you can see the obvious problems that might occur there (with having two separate IP types).

Most UUID libraries I've seen and written use [16]byte as the concrete UUID type.

Post reply on HN