Corrections for printf test with floating point limits arguments

[shajder]

According to work plan from issue #1058

[svenvh]

Thanks! Would you be able to provide some more details on what corrections were made here? I see a few changes to the testing scope, but not sure if I've caught all of them.

[shajder]

Thanks! Would you be able to provide some more details on what corrections were made here? I see a few changes to the testing scope, but not sure if I've caught all of them.

Yes, of course:

-applied suggestions from @franz , I've done some brief research and I think Michał has a point at (1) it is not certain that sqrt(-1.0) return -NaN, thus replaced with float nan(uint nancode). At point (2) Michał has partialy the point because current verification of test result ignores sign of NaN anyway, thus there is no point to distinguish between positive and negative NaN.

-strengthening the test by removing allowance of Inf/1.#IND00/NaN - according to the spec only INF, INFINITY, or NAN for uppercase conversion format or inf, infinity, or nan for lowercase conversion format are permissible.

-extending the frameworks functionality to test multiple conversion formats for the same input data with the same expected output, eg. entry:
{ { "%f", "%e", "%g", "%a" }, "1.0f/0.0f" }
schedule 4 tests expecting the same result inf or infinity (the same applies for single and half float).

-rest of corrections comes from clang-format sadly, I think there is no way around (except putting clang-format off comments which I am trying not to abuse)

[svenvh]

Thanks for the summary, that's very helpful. The changes look good to me.

[lakshmih]

We're reviewing this. Thanks.

[shajder]

@svenvh FYI: the same problem with skipped vector cases applied to this PR as well, I've corrected it but you may want to review again, thanks.

[bashbaug]

Thanks, LGTM.

There are a lot of extraneous blank lines in util_printf.cpp. How would folks feel about removing them? This might be a good time to do it...

[svenvh]

There are a lot of extraneous blank lines in util_printf.cpp. How would folks feel about removing them? This might be a good time to do it...

+1 for removing them, they're an eyesore. I would suggest doing that in a separate PR though (maybe after the other printf PR is merged too, to avoid merge conflicts).