[Bug c/71176] trunk/fixincludes/fixincl.c:162: bad % specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71176 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=78014 --- Comment #8 from Eric Gallager --- (In reply to Eric Gallager from comment #7) > (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? ...actually I guess we can't actually use that here; see discussion in bug 78014...
[Bug c/71176] trunk/fixincludes/fixincl.c:162: bad % specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71176 Eric Gallager changed: What|Removed |Added CC||xerofoify at gmail dot com --- Comment #7 from Eric Gallager --- (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?
[Bug c/71176] trunk/fixincludes/fixincl.c:162: bad % specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71176 Eric Gallager changed: What|Removed |Added CC||bonzini at gnu dot org --- Comment #6 from Eric Gallager --- svn blame says Paolo Bonzini wrote this code; cc-ing him
[Bug c/71176] trunk/fixincludes/fixincl.c:162: bad % specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71176 --- Comment #5 from Jonathan Wakely --- Patch posted to https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01511.html
[Bug c/71176] trunk/fixincludes/fixincl.c:162: bad % specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71176 --- Comment #4 from Eric Gallager --- (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?
[Bug c/71176] trunk/fixincludes/fixincl.c:162: bad % specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71176 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Severity|normal |enhancement
[Bug c/71176] trunk/fixincludes/fixincl.c:162: bad % specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71176 --- Comment #3 from Manuel López-Ibáñez --- (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.
[Bug c/71176] trunk/fixincludes/fixincl.c:162: bad % specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71176 --- Comment #2 from David Binderman --- (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.
[Bug c/71176] trunk/fixincludes/fixincl.c:162: bad % specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71176 Manuel López-Ibáñez changed: What|Removed |Added Keywords||easyhack Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-18 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez --- 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.
