Enable %u8/u16/u32/u64 and similar if PRINTF_SUPPORT_HUMAN_STYLE_SPECIFIERS is defined

[andrewvoznytsa]

Enable %u8/u16/u32/u64 and similar human-friendly fixed-size specifiers (like %d/x) are enabled if PRINTF_SUPPORT_HUMAN_STYLE_SPECIFIERS is defined.

That's super handy if types similar to Linux kernel's s8/u8/s16/u16/s32/u32/s64/u64 are in use and MS-specific specifiers like %I32d are not available.

Adding custom specifiers is basically vendor lock and in general should be avoided but in case of printing fixed-size ints it brings more value than harm - I'm super happy to stop doing %" PRIu64 " - just %u64 is much easier to remember and use.

Of course MS-specific specifiers could be used for similar goals but I think this library deserves its own cross-platform specifiers which are even better (shorter and easier to remember) than those from MS CRT.

That's my small attempt to thank all contributors for developing such great library.

[mickjc750]

It should be noted that this will cause compilation warnings for types larger than int. This is because the format checking will expect an unsigned int for %u.
It would also break any code intending to print an unsigned int followed by "32" or "64" etc, if any exists, which it probably doesn't.
Personally I don't see why people don't like %"PRIu64", is it the quotes concatenation that bothers people? or it's too long?

[andrewvoznytsa]

Well - the format-related warning is controlled by an option. %u32-like formats are controlled by preprocessor and should be explicitly enabled, thus making situation when 8/16/32/64 that follow format specifier are not width specifiers extremely unlikely. PRIu64 is a problem from all points of view - needs some effort to be memorized/is not super intuitive, needs ugly concatenation and is twice as long comparing to MS or my variants.

…

On Mon, 6 Nov 2023 at 22:45, Michael James Clift ***@***.***> wrote: It should be noted that this will cause compilation warnings for types larger than int. This is because the format checking will expect an unsigned int for %u. It would also break any code intending to print an unsigned int followed by "32" or "64" etc, if any exists, which it probably doesn't. Personally I don't see why people don't like %"PRIu64", is it the quotes concatenation that bothers people? or it's too long? Reply to this email directly, view it on GitHub <#164 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKJSBKSTKBQDY42WD6DBNLYDFK6NAVCNFSM6AAAAAA7AAI7XSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJWGU4TSOBVGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[eyalroz]

Let me start by saying that opening an issue is more appropriate than a PR, when it is not obvious a PR is awaited.

That aside - please explain why this should be supported, given that:

• You're asking for non-standard format specifiers.
• The specifiers you propose only duplicate the specifiers "%I8d", "%I16d", "%I32d", "%I64d" and "%I8u", "%I16u", "%I32u", "%I64u"
• Nobody else has asked for these so far (let's say, for the 6 years or so of the repository's existence, including Marco Paland's years)

[andrewvoznytsa]

This work has been done because of private needs. It is shared with you just in hope that it might be also useful for someone else, kind of 'thank you for all your previous work'. Feel free to drop the PR without merging if you think that it brings less than requires to merge it - it is absolutely OK for me as it does not affect my fork.

And %I8, according to MS specs, requires type specifier. The correct way to use it is %I8d, for example, not %I8.

[eyalroz]

Sorry for the belated reply.

And %I8, according to MS specs, requires type specifier. The correct way to use it is %I8d, for example, not %I8.

Yes, you're right, I just mistyped. The library does indeed need "%I8d", not just "%I8".

This work has been done because of private needs. It is shared with you just in hope that it might be also useful for someone else, kind of 'thank you for all your previous work'. Feel free to drop the PR without merging if you think that it brings less than requires to merge it - it is absolutely OK for me as it does not affect my fork.

Ok. I appreciate the PR, and the sentiment. If this were the only way to explicitly specify size via number of bits, or if it were a very popular variant on C-standard specifiers, I would accept the PR. But for now, I believe I have to regretfully decline :-(