[Bug stdio/24466] Feature request: provide special printf formats for intXX_t

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=24466

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #1 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to nfxjfg from comment #0)
> Currently, the standard way (and only way if you want to be portable) to
> format a value of e.g. int32_t type is int32_t v; printf("%" PRIi32, v);
> 
> I think this is very awkward and lowers readability. A dedicated set of
> printf format specifiers would be more appropriate (technically, they're
> called length modifiers). I propose that glibc should add such qualifiers as
> a GNU extension.

I don't have a strong position here, but 'awkward' and 'lowers readability' is
quite vague concepts imho. I think we will need a slightly better reason to
introduce potentially GNU extensions that would deviate from the standard and
other implementations.

> 
> Ideally, the syntax should encode the full bit width of the type passed to
> it, and due to how printf format specifiers work, the sign of the type. It's
> clear that it should be relatively similar to how the PRI* macro names are
> composed.
> 
> One idea would just to base this on Microsoft's printf extensions. Microsoft
> uses "I32" for 32 bit values, "I64" for 64 bit values, and "I" for
> size_t/ptrdiff_t. I think they had the right idea here. The format specifier
> consists of a prefix "I" that is not used by any other standard, followed by
> the bit width of the type, followed by the sign.
> 
> Maybe it would be nicer if the sign came before the bit width (like in the
> PRI* macros), but on the other hand, it helps to disambiguate parsing of the
> bit width (e.g. if a number follows the format specifier).
> 
> Extended over Microsoft's extension, I suggest the following:
> 
>       I64u => uint64_t       (MS)
>       I64d =>  int64_t       (MS)
>       I32u => uint32_t       (MS)
>       I32d =>  int32_t       (MS)
>       I16u => uint16_t       (GNU)
>       I16d =>  int16_t       (GNU)
>       I8u  => uint8_t        (GNU)
>       I8d  =>  int8_t        (GNU)
>       Iu   => size_t         (redundant with %z)
>       Id   => ptrdiff_t      (redundant with %t)
> 
> This could cover longer type names added in the future as well:
> 
>       I128u => uint128_t
>       I12u  => uint12_t      (unlikely to exist, but unambiguous)

Unfortanelly 'I' is handled a flag character for decimal integer conversion (i,
d, u) the output uses the locale's alternative output digits.  It means that
all about options are already valid printf inputs (for instance I32d will
printf a number using locale rules (through _i18n_number_rewrite function with
32 characters as field width).

It means that a potentially GNU extension won't be portable with MS extension
as is.

> 
> But other approaches which cover all intXX_t types now and in the future
> would be appreciated. Anything to reduce ugliness of code, improve
> readability, and as consequence to reduce bugs and security issues. It helps
> to make the intXX_t types more "first class" as well, since no ugly hacks
> for printf are needed anymore.

The 'reduce bugs and security issues' is a strong reason to add such extension.
Could you provide examples where current practices are introducing readl world
cases of bugs and security issues?

> 
> Note that the standard already has a precedent for such type aliases. For
> example "%z" is for size_t, even though it would have been possible to avoid
> it by adding a "PRIz" macro or such. This may be a sign that the standard
> would not be terribly opposed to such an addition.

My understanding is size_t predates C99 inttypes.h.


[1]
https://docs.microsoft.com/en-us/cpp/c-runtime-library/format-specification-syntax-printf-and-wprintf-functions?view=vs-2019

-- 
You are receiving this mail because:
You are on the CC list for the bug.