[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

--- Comment #3 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to nfxjfg from comment #2)
> Yes, since this is not strictly necessary, the arguments for it are going to
> be sort of vague and fuzzy.
> 
> I justify better readability with the fact that with this extension, the
> whole format specifier is contained within the string literal (purely
> lexically speaking). The additional quotes and the PRI prefix add noise and
> thus lower readability. Format strings are already a bit hard to read, and
> interrupting them with that additional "unusual" looking noise makes it
> harder.
> 
> Claiming less bugs and thus a security advantage from higher readability is
> probably bit weak, although it's definitely a real effect. Security bugs due
> to format string mistakes do exist in general. But it's a bit hard to argue
> here, because the main way to combat them is recommending -Werror=format to
> programmers. Still, programmers may pick less appropriate builtin types over
> intXX_t just to avoid the ugliness associated with intXX_t, one of which are
> format specifiers. For example, if a programmer were to cast int64_t to long
> just so the shorter "l" format specifier could be used, it may be possible
> that this adds overflow issues on 32 bit platforms. In all of these cases
> the programmer could be blamed for not following good practices, but my
> argument is that such artificial inconveniences are simply one cause of bugs
> due to carelessness. Not sure if I should pursue this argument further.

I agree that we can and GCC has done a nice job in improving the compiler
warning for using mismatched types on both printf and scanf.  And I also tend
to see this should be the focus on improving for a more generic solution,
instead of adding more type specifiers to printf/scanf.

Also, in your example, it would also require proper compiler support to warn
that narrowing down the range of the variable using a cast might incur in a
mismatched specifier. Also, adding new specifiers would require adding
counter-part support on compilers which also might take time (it might be easy
for Microsoft which packs a complete toolchain solution, but for glibc it would
require to coordinate it the compiler).

> 
> Ultimately, I think the C standard should never have added these PRI macros.
> To be honest, it sounds like a hack so that they could have useful intXX_t
> types without having to argue with the guys who own the printf format
> specifiers, or something.

One advantage of the PRI macros is they are composable: with C99 specifying
that both uint64_t and long long are no longer compiler extension, printf/scanf
should also support the types. It simplifies compiler and runtime
implementation.

> 
> One other thing that I would love to see is if the compiler could warn if
> the user is passing types other than intXX_t for these new format
> specifiers, even if the type is the same (i.e. base it on whether an intXX_t
> typedef was used). This is up to the compiler (and I don't know if gcc could
> do it or if it would be willing to do it), and special format specifiers
> might enable it to do so.
> 
> Is there any formal process/requirements involved with GNU extensions? I
> assume they were added much more frivolously in the past, while you're
> trying to be more careful with not adding potentially pointless things.

The best course of action is to discuss it on libc-alpha maillist. Usually,
bugzilla is not the right to place to discuss API extensions.

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