Non-unsafe functions for PODs #8
Conversation
Effectively just uses a marker trait to waive any responsibility
Also, is #[cfg(stage0)] the correct thingy to enable {i,u}128s with
Ref: #5
There was a problem hiding this comment.
Things look ok other than the typo, but I'm starting to feel that our function naming and categorization approach won't scale well. As at least 2 variants, sometimes 3 or 6, are created for each case, things may explode quickly. Let's throw in a new issue on this, it's better to change the API sooner than later.
src/pod.rs
Outdated
| /// Marker trait for `guarded_transmute_pod_*()` functions. | ||
| /// | ||
| /// *Nota bene*: `bool`s aren't *actually* non-`unsafe` to transmute, because they're restricted to being `0` or `1`, | ||
| /// which means it's UB to transmute an arbitrary byte to into a `bool`. |
src/pod.rs
Outdated
| /// which means it's UB to transmute an arbitrary byte to into a `bool`. | ||
| /// | ||
| /// *Nota bene*: if you transmute into a floating-point type you will have a chance to create signaling NaNs | ||
| /// (judgement's still out as to whether they're legal). |
There was a problem hiding this comment.
Well, it's not like they're illegal, but signaling NaNs are usually undesirable here. They can be converted to quiet NaNs in separate functions.
There was a problem hiding this comment.
I'm taking "separate functions" as "user normalises" (because, (a) that's out of scope, and (b) do you know what user wants)?
There was a problem hiding this comment.
I actually meant that we should include it. It has potential use cases (do want), and if the user wants sNaNs anyway, we can invite them to use the unsafe functions.
src/pod.rs
Outdated
| impl PodTransmutable for u64 {} | ||
| impl PodTransmutable for i64 {} | ||
| impl PodTransmutable for char {} | ||
| #[cfg(stage0)] |
There was a problem hiding this comment.
Is this cfg() argument right, btw?
There was a problem hiding this comment.
Hmm, byteorder seems to be using #[cfg(feature = "i128")]. IMO we should do the same.
There was a problem hiding this comment.
Ah, cool. I stole this from libcore so I wasn't sure.
There was a problem hiding this comment.
I mean, it has its own conditional feature for this (code). The real Rust compiler feature for these types is feature(i128_type).
There was a problem hiding this comment.
Does that mean that #[cfg(i128_type)] is correct, or?
Turns out it is.
|
Oh by the way, don't close #5 yet because we should at least do something about the floaty ones. |
|
Fixed typo, feature gate and float |
…t NaNs out of signaling ones
|
Released in v0.5.0. |
Working PR, but something concrete at least.
Ref: #5