Add hexadecimal float/double parsing and formatting support (IEEE 754:2008)

[Copilot]

Implementation Plan for Hexadecimal Float/Double Parsing and Formatting

• 1. Add HexFloat composite style to NumberStyles enum
• 2. Update ValidateParseStyleFloatingPoint to allow AllowHexSpecifier with appropriate flags for float/double parsing
• 3. Implement hex float parsing logic in Number.Parsing.cs
  • 3a. Create helper methods to parse hex significand and binary exponent
  • 3b. Integrate with existing TryParseFloat method
• 4. Implement hex float formatting logic in Number.Formatting.cs
  • 4a. Add support for 'X'/'x' format specifier for floats/doubles
  • 4b. Create helper methods to convert float/double to hex representation
• 5. Add comprehensive test cases for parsing and formatting
  • 5a. Add tests for valid hex float formats
  • 5b. Add tests for invalid formats
  • 5c. Add roundtrip tests
  • 5d. Add tests for float, double, and Half types
  • 5e. Add formatting tests with precision
• 6. Build and test the implementation

Code Review Feedback Addressed

Hot Path Performance (ValidateParseStyleFloatingPoint)

• Restored manual throw helper outlining for hot path performance
• Added local throw helper methods with [DoesNotReturn] attribute
• Added required using System.Diagnostics.CodeAnalysis;

FormatFloatAsHex Bugs Fixed

• Fixed mantissa normalization to output leading digit as 1 (not 8)
• Properly normalized subnormal numbers by counting leading zeros
• Fixed nibble output to emit single character (not "0A" for hex A-F)
• Shifted significand so leading 1 is at bit 60 for correct hex digit output
• Adjusted exponent calculation accordingly

FormatInt32 Improvements

• Removed unused parameters (precision, format, info)
• Eliminated string allocation by formatting digits directly into ValueListBuilder
• Renamed to FormatInt32ToValueListBuilder for clarity

Parser Optimization

• Used | 0x20 trick for case-insensitive 'x'/'X' comparison

Comprehensive Testing

• Added extensive parsing tests for double, float, and Half types
• Added formatting tests with various precision levels
• Covered edge cases: zero, negative, denormals, max/min values, epsilon
• Tested case variations (0x/0X, p/P, a-f/A-F)
• Tested whitespace handling
• Tested different formats (integer only, fraction only, both)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Add the ability to parse/format a float/double from/to a hexadecimal literal</issue_title>
<issue_description>### Part of #27204

In IEEE 754:2008 part 5.12.3, transfering a float/double from/to an external hexadecimal-significand character sequence representing finite number is requested while we don't have it yet. The pattern is like this: (regex)

[+-]?0[xX](?:[\da-fA-F]*\.[\da-fA-F]+|[\da-fA-F]\.?)(?:[pP][+-]?\d+)?

notice that this is slightly different to the standard based on the discussion below, which talked about the exponent part

which means:

valid	invalid
+0x7ff.3edp+1	+7ff.3edp-1
0x7ff.3edp+1	0x7ff.3ede+1
0x7ff.3edp1	0x7ff.3uup1
+0x7ff.3edp1	0x7ff.3ed
+0X7FF.3EDP1	0X7FF.3ED
-0x7ff.3edp1	0x7ff_3edp-1
0x7ff.	+-0x7ff.3edp-1
0x7ff	0x7fu.3edp-1
0x.3edp-1	0x.p-1

benefits

• Easier parsing for native hexadecimal float/double. for example, 0x0.ffp0 is the equivalent of 0.99609375 while using less chars. Same for formatting as it reduces the size of string to transfer.
• Parsed number is percise in the limit of float/double's limitations. Since both float and double are based on raw bit, transistion from hexadecimal literal to them would be easier and without rounding if they are in the limitation. parsing decimals, on the other hand, would often has to round.
• It's in IEEE 754:2008/2019 standard, so it's necessary to add it.

proposal APIs

namespace System.Globalization {
    [Flags]
    enum NumberStyles {
        // ...,
        HexFloat = AllowLeadingWhite | AllowTrailingWhite | AllowLeadingSign | AllowHexSpecifier | AllowDecimalPoint
        // ,...
    }
}

And let Numbers.ParseDouble/Single(string s, NumberStyles style[, NumberFormatInfo info]) accept Numberstyles.HexFloat (or it without NumberStyles.AllowDecimalPoint) and correctly parse string.

Edit Numbers.FormatDouble/Single(ref ValueStringBuilder sb, double/float value, ReadOnlySpan<char> format, NumberFormatInfo info) so that they can correctly identify X specifier (which is also used for outputting integers in hex) which may have a trailing precision specifier, and correctly format it. </issue_description>

Comments on the Issue (you are @copilot in this section)

@stephentoub cc: @tannergooding @tannergooding Thanks for opening this, its good to see additional customer wants for these areas 😄

It is partially tracked by https://github.com/dotnet/corefx/issues/31901 (which is IEEE 754:2008 compliance) and by #1387 (which is IEEE 754:2019 compliance), but those are largely meta issues and the individual proposals will be easier to take through API review.

The format specifier can be broken down into:

sign:           [+-]?
hexIndicator:   0[xX]
hexSignificand: (?:[\da-fA-F]*\.[\da-fA-F]+|[\da-fA-F]+\.?)
decExponent:    [pP][+-]?\d+

The terminal [fFdD]? listed is not actually part of the IEEE specification and should be excluded.
I also updated hexSignificand to clarify that just . is not valid.

The computed value is hexSignificand * 2^decExponent.

So, for example if you have 0x1.234p0 this is:

• 0x1 == 1
• 0x234 * 16^-3 == 564 * 16^-3 == 0.1376953125
• 1.1376953125 * 2^0 == 1.1376953125</comment_new>
  <comment_new>@tannergooding
  Even though this isn't a new API, I believe we still want to take it through API review since it is modifying an existing API.

We would want to check it against the compat bar and make the necessary decisions around what flags would be used to support this functionality and ensure that we wouldn't accidentally introduce any breaking changes, etc.</comment_new>
<comment_new>@tannergooding
I don't see why it wouldn't, provided it was still valid according to the IEEE requirements.</comment_new>
<comment_new>@tannergooding
I don't believe its out of scope, as I said as long as its still valid according to the IEEE requirements, it should be fine.

There are "paths" where the decimal point isn't required and so the user should fully be able to specify that hex is allowed but decimal-point is not. It's an advanced scenario, but the number parser already supports it and will continue doing so even if we add support for hex, so there is no reason to block it. The interesting scenario would be whether or not to allow the exponent to be optional and to default to 0 (which would still be valid based on the normal conversion rules, etc).

sign:           [+-]?
hexIndicator:   0[xX]
hexSignificand: (?:[\da-fA-F]*\.[\da-fA-F]+|[\da-fA-F]+\.?)
decExponent:    [pP][+-]?\d+

• The sign i...

Fixes #1630

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

[stephentoub]

@copilot, there are also some analyzer failures:

D:\a\_work\1\s\src\libraries\System.Private.CoreLib\src\System\Number.Formatting.cs(639,96): error IDE0060: Remove unused parameter 'precision' (https://learn.microsoft.com/dotnet/fundamentals/code-analysis/style-rules/ide0060) [D:\a\_work\1\s\src\coreclr\System.Private.CoreLib\System.Private.CoreLib.csproj]
D:\a\_work\1\s\src\libraries\System.Private.CoreLib\src\System\Number.Formatting.cs(639,115): error IDE0060: Remove unused parameter 'format' (https://learn.microsoft.com/dotnet/fundamentals/code-analysis/style-rules/ide0060) [D:\a\_work\1\s\src\coreclr\System.Private.CoreLib\System.Private.CoreLib.csproj]
D:\a\_work\1\s\src\libraries\System.Private.CoreLib\src\System\Number.Formatting.cs(639,140): error IDE0060: Remove unused parameter 'info' (https://learn.microsoft.com/dotnet/fundamentals/code-analysis/style-rules/ide0060) [D:\a\_work\1\s\src\coreclr\System.Private.CoreLib\System.Private.CoreLib.csproj]

[Copilot]

Pull Request Overview

This PR implements IEEE 754:2008 section 5.12.3 support for parsing and formatting floating-point numbers using hexadecimal significand representation. The implementation allows parsing values like 0x1.8p0 (= 1.5) and formatting floats/doubles to hex representation using the 'X'/'x' format specifiers.

Key Changes:

• Adds NumberStyles.HexFloat enum value for hexadecimal float parsing
• Implements comprehensive hex float parsing logic with proper IEEE 754 conversion
• Adds hex float formatting support using 'X'/'x' format specifiers

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
NumberStyles.cs	Adds HexFloat composite style flag
System.Runtime.cs	Updates reference assembly with new HexFloat enum value
NumberFormatInfo.cs	Updates validation to allow hex specifier for floating-point with specific constraints
Number.Parsing.cs	Implements complete hex float parsing with IEEE 754 conversion
Number.Formatting.cs	Adds hex float formatting functionality
DoubleTests.cs	Adds basic test cases for hex float parsing

[Copilot]

Potential integer overflow when negating int.MinValue. The negation of int.MinValue overflows and remains negative, which could cause incorrect behavior.

Suggested change

	vlb.Append(TChar.CastFrom('-'));
	vlb.Append(TChar.CastFrom('-'));
	if (value == int.MinValue)
	{
	// int.MinValue cannot be negated; use its magnitude as uint
	string numStr = ((uint)int.MinValue).ToString();
	foreach (char c in numStr)
	{
	vlb.Append(TChar.CastFrom(c));
	}
	return;
	}

[gfoidl]

Could use Math.DivRem.

[gfoidl]

Suggested change

	if (index + 1 >= value.Length ||
	if (index >= value.Length - 1 ||

To avoid potential overflow (just to be super pedantic about this).