Samuel Tardieu

I've restructured the code to make names more explicit, and added uucode tests to the partial parsing function.

> Hi! Thanks! I think this is mostly correct, but I think it should be implemented slightly differently. A problem with this implementation is that the base is lost. Here's...

I have implemented a new number parser which can also cope with hexadecimal floats. I have put it in another module as to differentiate between the part which emits error...

As far as I know, the only remaining issue before we can activate the printf fuzzer (in matching stderr mode) is that double quotes are escaped when printed by uutils...

The latest push just adds a new test for the error message corresponding to a larger single character: ```bash $ target/debug/coreutils printf %d "'abc" printf: warning: bc: character(s) following character...

The failing chown test seems unrelated to those changes and fails for me the same way locally with and without this patch.

Btw, are different parameters used for configuring Clippy? The windows running requires that I had a `#[allow(clippy::cognitive_complexity)]` to the parse function, while I cannot reproduce this on Linux.

The failing macos/x86_64 check seems unrelated.

Yes, and uutils is more consistent than GNU coreutils here.

The standard library now includes `.abs_diff()` on primitive types (see [here](https://doc.rust-lang.org/std/primitive.u32.html#method.abs_diff) for example). Would it make sense to add this as a trait now?