Fixed handling of "0-"

[stefano-zanotti-88]

This fix is extracted from #315, as it is a bug that needed fixing for that PR, but appears in other contexts too.

printf("%0*.3f", -10, 1.234); // before "1.23400000", now "1.234     "

[charlesnicholson]

Thanks for the PR! Could I ask a favor on these tiny ones - I understand that you're having troubles with the build system. (which, by the way, do you have access to a linux VM or WSL2 or anything like that? I wonder if that would be easier)

But, for small PRs like this the turnaround is often not too bad if you use the CI runs as your build system; you can click on the "Checks" tab and click on any of the failed builds (they have red x icons), and you'll see the test failure- in this case, it looks to just be one test case:

/Users/runner/work/nanoprintf/nanoprintf/tests/conformance.cc:64:
TEST CASE:  conformance to system printf
  signed int

/Users/runner/work/nanoprintf/nanoprintf/tests/conformance.cc:60: FATAL ERROR: REQUIRE( npf_result == expected ) is NOT correct!
  values: REQUIRE( 00 ==  0 )

which makes sense, given the changes here. Even if you can't run the tests locally, fixing little ones like this might be easy enough to do "remotely". (I'm happy to pull in and migrate tests for larger PRs like the %a support etc, if building the tests remains impossible).

(Also sorry for the delay, I've been sick!)

[stefano-zanotti-88]

I had to merge it with #328 for a proper fix. See commit b457f9b

Then, I added a nicer default for %p, which is related to these padding issues; see 6d4d12f .
This is IB, so maybe you don't want to accept that, to save a few bytes of code.

[stefano-zanotti-88]

Maybe I'll try with WSL2.
As for the fix, it seems there are still some issues with the various NPF option combinations, which I'm still trying to sort out.

[stefano-zanotti-88]

I've fixed all the issues, and reverted the changes about %p -- they need a different PR
There are still failing cases. However, at least one of those cases should be revisited:

nanoprintf/tests/unit_parse_format_spec.cc

Lines 151 to 153 in 49628bd

	REQUIRE(npf_parse_format_spec("%0-u", &spec) == 4);
	REQUIRE(spec.left_justified);
	REQUIRE(!spec.leading_zero_pad);

In my view, it is not correct to expect the parsing to produce !leading_zero_pad. The flag is there, and it can only be properly ignored after fetching the dynamic precision (if any), which is not part of parsing.
I think these semantic constraints should be left to the caller (as is done to the main caller of the parser, ie npf_vpprintf, and not addressed by the parser.

I haven't changed that test yet, I'll be waiting for your feedback.

[charlesnicholson]

Ah, I see, I just left feedback on the %p PR you opened #329 - I see the issue now, that the spec can't be resolved until the dynamic star args are read, and the latter only happens in the actual formatting code. I don't mind this change because of the nature of it, but it does mean changing or deleting existing unit tests that harnessed the previous logic of "npf_parse_format_spec only returns legal combinations".

[stefano-zanotti-88]

Addressed by #340