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

Open
Timmmm opened this Issue Feb 11, 2017 · 9 comments

Comments

Projects
None yet
7 participants
@Timmmm
Copy link

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.

@rkruppe

This comment has been minimized.

Copy link
Member

rkruppe 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

This comment has been minimized.

Copy link
Contributor

est31 commented Feb 11, 2017

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

@Timmmm

This comment has been minimized.

Copy link
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-

This comment has been minimized.

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

This comment has been minimized.

Copy link
Member

Mark-Simulacrum commented May 27, 2017

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.

@dtolnay

This comment has been minimized.

Copy link
Member

dtolnay commented Nov 18, 2017

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

@frewsxcv

This comment has been minimized.

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-

This comment has been minimized.

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

This comment has been minimized.

Copy link
Member

frewsxcv commented Dec 17, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.