Fix: make sure fprintf uses an unsigned marker when an unsigned value is given

[obones]

Fixes C6340 as reported in #1866

[zuckschwerdt]

Not sure if works at intended, needs more research.
E.g. there is #define UINT16_MAX (65535) (or maybe #define UINT16_MAX 0xffff) which acording to literal rules will be int.
And in the printf's the (unsigned) shorts will be values will be coerced to integer according to promotion rules.

[merbanan]

Well the iterators could be changed to int. But int_t types should keep their size IIRC.

[obones]

Under Visual Studio, it tells me that UINT16_MAX is defined like this in stdint.h

#define UINT16_MAX       0xffffui16

So in that instance, it clearly is a uint16_t

[zuckschwerdt]

Then let's start with the observation that all those instances were uint16_t. And as printf args they were not in there "native" size but all were coerced to int. This change now coerces to unsigned int. Doesn't matter anyway and both share the same conversion rank. But note that this likely changed the emitted code, not just tidied up some specifiers ;)

[merbanan]

But do we have different definitions of UINT16_MAX on different platforms ? That would be annoying.

[zuckschwerdt]

I don't think that matters, the literal would be at least uint16_t anyway and literal rules use the smallest type that fits the number. And any larger integral type will also fit. In the printf's we chose int, which can represent uint16_t. now we chose unsigned and the same applies ;) It should only matter to the compilers that we don't use hd, but hu and any higher rank should be fine.

[zuckschwerdt]

aside: it's easier for me to compile that changelog if commit messages follow https://triq.org/rtl_433/CONTRIBUTING.html#commit-messages
I.e. the verb is not followed by a colon, and the area-of-work would preferably be "minor:" here -- I can just filter those out as not relevant to the changelog :)

[obones]

aside: it's easier for me to compile that changelog if commit messages follow https://triq.org/rtl_433/CONTRIBUTING.html#commit-messages

Bummer, I thought I did, but I now see that I missed the first part altogether. I'll keep that in mind for the next ones