Bug 71176 - trunk/fixincludes/fixincl.c:162: bad % specifier
Summary: trunk/fixincludes/fixincl.c:162: bad % specifier
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 7.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL: https://gcc.gnu.org/ml/gcc-patches/20...
Keywords: easyhack, patch
Depends on:
Blocks: cppcheck
  Show dependency treegraph
 
Reported: 2016-05-18 15:34 UTC by David Binderman
Modified: 2022-05-01 16:45 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2016-05-18 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Binderman 2016-05-18 15:34:55 UTC
trunk/fixincludes/fixincl.c:162]: (warning) %d in format string (no. 2) requires 'int' but the argument type is 'size_t {aka unsigned long}'.

Source code is

    tSCC zFmt[] =
      "\
Processed %5d files containing %d bytes    \n\
Applying  %5d fixes to %d files\n\
Altering  %5d of them\n";

    fprintf (stderr, zFmt, process_ct, ttl_data_size, apply_ct,
             fixed_ct, altered_ct);

Suggest use %lu for size_t, not %d.
Comment 1 Manuel López-Ibáñez 2016-05-18 19:42:41 UTC
I wonder why GCC -Wformat does not catch this, since "static const char" literals contents should be visible as formatting strings. In this case, it doesn't even make sense to use a separate variable.
Comment 2 David Binderman 2016-05-18 19:57:09 UTC
(In reply to Manuel López-Ibáñez from comment #1)
> I wonder why GCC -Wformat does not catch this, since "static const char"
> literals contents should be visible as formatting strings. In this case, it
> doesn't even make sense to use a separate variable.

There is a much simpler explanation for this.

The compiler only sees code that gets through the preprocessor.

The code in question has

#ifdef DO_STATS

around it.

Still worth fixing, in my view. 2e9 bytes isn't a lot of source code these days.
Comment 3 Manuel López-Ibáñez 2016-05-18 20:06:25 UTC
(In reply to David Binderman from comment #2)
 
> The compiler only sees code that gets through the preprocessor.

> Still worth fixing, in my view. 2e9 bytes isn't a lot of source code these
> days.

In that case, I would say "not really". If you have any time to contribute to GCC, there are plenty more important things that you could do with your time. But there is no harm in keeping it open in case someone disagrees and decides to fix it.
Comment 4 Eric Gallager 2018-10-28 03:08:59 UTC
(In reply to David Binderman from comment #2)
> (In reply to Manuel López-Ibáñez from comment #1)
> > I wonder why GCC -Wformat does not catch this, since "static const char"
> > literals contents should be visible as formatting strings. In this case, it
> > doesn't even make sense to use a separate variable.
> 
> There is a much simpler explanation for this.
> 
> The compiler only sees code that gets through the preprocessor.
> 
> The code in question has
> 
> #ifdef DO_STATS
> 
> around it.
> 
> Still worth fixing, in my view. 2e9 bytes isn't a lot of source code these
> days.

Where is DO_STATS supposed to be defined?
Comment 5 Jonathan Wakely 2019-01-07 15:53:15 UTC
Patch posted to https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01511.html
Comment 6 Eric Gallager 2019-09-28 05:08:53 UTC
svn blame says Paolo Bonzini wrote this code; cc-ing him
Comment 7 Eric Gallager 2022-05-01 16:45:49 UTC
(In reply to Jonathan Wakely from comment #5)
> Patch posted to https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01511.html

I thought the format code for size_t was %zu?