Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

f32, f64 missing from_le, from_be, to_le, to_be, swap_bytes implementation #39742

Closed
Timmmm opened this issue Feb 11, 2017 · 12 comments
Closed
Labels
C-feature-accepted Category: A feature request that has been accepted pending implementation. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@Timmmm
Copy link
Contributor

Timmmm commented Feb 11, 2017

For all the integer primitives there are functions for converting the endianness: from_le, to_le, from_be, to_be and swap_bytes (they probably should be a trait but they aren't for whatever reason).

The floating point types f32 and f64 don't have these methods defined.

@hanna-kruppe
Copy link
Contributor

hanna-kruppe commented Feb 11, 2017

Can you explain why they should have those methods? Floating point types aren't a natural choice for bit twiddling. They don't even have more fundamental bit manipulation operations such as bitwise operators or shifts/rotates. The usual way to work with the bit representation of floats is to turn them into integers with the same number of bits, and manipulate that integer.

@est31
Copy link
Member

est31 commented Feb 11, 2017

There is also the issue of signaling NaN's. See more discussion on this in #39271.

@Timmmm
Copy link
Contributor Author

Timmmm commented Feb 11, 2017

I'm wrapping libsoundio and that allows audio devices to support little and big endian floating point samples. These functions would be useful for converting between those.

For example I have this in a macro, which works for all the integer types, but not floating point types:

	fn from_raw_le(ptr: *const u8) -> Self {
		Self::from_le( unsafe {
			*(ptr as *const _)
		} )
	}

See also wikipedia. Finally I feel like they should be there just for completeness.

@tbu-
Copy link
Contributor

tbu- commented Mar 7, 2017

This particular function would be unsafe for floats btw, arbitrary bit patterns might be signaling NaNs for floats.

@Mark-Simulacrum
Copy link
Member

I think we could have these, though it's not clear to me that we should. They'd certainly have to be unsafe, I think.

@Mark-Simulacrum Mark-Simulacrum added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label May 27, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 27, 2017
@dtolnay dtolnay added C-feature-accepted Category: A feature request that has been accepted pending implementation. and removed C-feature-request Category: A feature request, i.e: not implemented / a PR. labels Nov 18, 2017
@dtolnay
Copy link
Member

dtolnay commented Nov 18, 2017

This seems reasonable to me. I would consider a PR to add these.

@frewsxcv
Copy link
Member

frewsxcv commented Dec 17, 2017

For f32::swap_bytes, would it be sufficient to just transmute to u32 and call u32::swap_bytes?

@tbu-
Copy link
Contributor

tbu- commented Dec 17, 2017

I think it would be better to not store floating points of nonnative endian in f32 or f64, creating a wrapper type for that sounds safer (as you won't forget to cast it).

@frewsxcv
Copy link
Member

Just to clarify my last comment, i'm talking about the implementation of f32::swap_bytes, just wondering the easiest way to accomplish the byte swap

@steveklabnik
Copy link
Member

Triage: no change

@tbu-
Copy link
Contributor

tbu- commented Dec 9, 2019

@steveklabnik Since this issue was created, we have created alternative methods to convert floats from/to bytes in big/little endian: #60446.

@Timmmm
Copy link
Contributor Author

Timmmm commented Dec 10, 2019

Yeay!

@Timmmm Timmmm closed this as completed Dec 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-accepted Category: A feature request that has been accepted pending implementation. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

8 participants