Replaced test values for hexfloat and printf to avoid ambiguity

[shajder]

Fixes #1335 according to the issue description.

@alycm replaced with straightforward values in terms of hex float representation

[bashbaug]

We pass the test with these changes FWIW, but we didn't have a problem with the prior test either, so I'm not sure how much value this brings.

Can you please explain how choosing different floating-point values avoids the ambiguity? If I'm reading the StackOverflow link from the issue correctly every finite and non-zero floating-point number has four valid hex float representations, so choosing different floating-point values won't necessarily help.

[shajder]

We pass the test with these changes FWIW, but we didn't have a problem with the prior test either, so I'm not sure how much value this brings.

Can you please explain how choosing different floating-point values avoids the ambiguity? If I'm reading the StackOverflow link from the issue correctly every finite and non-zero floating-point number has four valid hex float representations, so choosing different floating-point values won't necessarily help.

@bashbaug this is correct, theoretically, multiple hexadecimal representations exist for the same floating-point value (like 0.5), such as 0x1p-1, 0x2p-2, 0x4p-3, etc.. In practice most (all?) implementations of the C standard library consistently use normalized form that maximizes the exponent which will result in 0x1p-1. I hoped for more feedback from vendors and correct that case only if someone would complain, or should I add new functionality to verify all four cases anyway ? Thanks

[bashbaug]

@alycm filed the related issue and may be able to provide additional guideance.

[bashbaug]

Discussed in the September 9th teleconference. We don't think this PR will fix the fundamental problem, but somebody from Imagination (ping @paulfradgley) will confirm.

[bashbaug]

Closing without merging. This doesn't fix the reported issue, so we will need an alternative solution.

[shajder]

@bashbaug Could we reopen this PR? Based on the earlier discussion, I was expecting feedback from other vendors and waited accordingly. I’ve now added a new commit with a minimal and non-intrusive alternative proposal. Could we revisit this solution?

[bashbaug]

Reopened as per request above.

[shajder]

I've introduced an alternative approach that performs a fallback test when enabled in the test configuration and the regular test fails. This solution verifies %a float formatting by parsing the generated hexadecimal representation back into a float using strtof/strtod and comparing it to the original value. This round-trip check correctly accepts all valid representations without relying on exact string matching.