To match the existing DoubleToInt64Bits and Int64BitsToDouble. This is important for binary serialization tools to get hold of the underlying value without requiring unsafe themselves, which may not be accepted.
Example usage: IO / sockets tools, raw protocol tools, network libraries, serialization tools.
Existing 64-bit API
public static long BitConverter.DoubleToInt64Bits(double value);
public static double BitConverter.Int64BitsToDouble(long value);
However, no 32-bit api exists
Proposed 32-bit API
To mimic existing API:
public static int BitConverter.SingleToInt32Bits(float value);
public static float BitConverter.Int32BitsToSingle(int value);
Rationale and Usage
Exactly the same as pre-existing 64-bit API:
- caller can populate an
int (perhaps via shift ops and network access / stream, perhaps via raw memory access), and force it to a float, for example during deserialization
- caller can consume a
float and force it to an int (perhaps for use on network access / stream via shift, perhaps via raw memory access), for example during serialization
Details
To follow same rules and conventions as the existing 64-bit api, which is to say: uses straight unsafe cast - does not explicitly consider machines where integer and floating-point endianness are different (integer big-endian, floating-point little-endian), but is fine on both big-endian and little-endian machines - in reality the endianness matches. To emphasise: there is nothing in here that is different from the expectations of the existing 64-bit api. It would be inconsistent to have the 32-bit API operate with different expectations to the 64-bit api, and it would be a breaking change to alter the expectations of the existing 64-bit api.
Pull Request
A pull request is available with the proposed implementation (comments etc based on the existing 64-bit API): dotnet/coreclr#833
Issues
None known; not a breaking change, and no overload resolution issue since uniquely named static non-extension methods.
Discussion Point
Possible doubt over relevancy of comments and assertion. This is addressed separately in https://github.com/dotnet/coreclr/issues/834
Migrated from https://github.com/dotnet/coreclr/issues/832
To match the existing
DoubleToInt64BitsandInt64BitsToDouble. This is important for binary serialization tools to get hold of the underlying value without requiring unsafe themselves, which may not be accepted.Example usage: IO / sockets tools, raw protocol tools, network libraries, serialization tools.
Existing 64-bit API
However, no 32-bit api exists
Proposed 32-bit API
To mimic existing API:
Rationale and Usage
Exactly the same as pre-existing 64-bit API:
int(perhaps via shift ops and network access / stream, perhaps via raw memory access), and force it to afloat, for example during deserializationfloatand force it to anint(perhaps for use on network access / stream via shift, perhaps via raw memory access), for example during serializationDetails
To follow same rules and conventions as the existing 64-bit api, which is to say: uses straight unsafe cast - does not explicitly consider machines where integer and floating-point endianness are different (integer big-endian, floating-point little-endian), but is fine on both big-endian and little-endian machines - in reality the endianness matches. To emphasise: there is nothing in here that is different from the expectations of the existing 64-bit api. It would be inconsistent to have the 32-bit API operate with different expectations to the 64-bit api, and it would be a breaking change to alter the expectations of the existing 64-bit api.
Pull Request
A pull request is available with the proposed implementation (comments etc based on the existing 64-bit API): dotnet/coreclr#833
Issues
None known; not a breaking change, and no overload resolution issue since uniquely named static non-extension methods.
Discussion Point
Possible doubt over relevancy of comments and assertion. This is addressed separately in https://github.com/dotnet/coreclr/issues/834