Created attachment 50757 [details] Patch to fix -Werror=format-security errors As mentioned in bug 100207, Arch Linux recently starting compiling its packages with the -Werror=format-security option. In this bug report, I attach two patches that enable compiling gcc with that flag. The first patch expliclity adds "%s" format strings to functions that pass its arguments to printf. However, during my testing, I found that libgcc uses -Wno-format in its CFLAGS, making the flags inconsistent. It seemed that adding the --enable-build-format-warnings should remove the -Wno-format option from the compile flags, but it didn't seem to work as expected, leading to errors like this: /build/gcc/src/gcc-build/./gcc/xgcc -B/build/gcc/src/gcc-build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -fno-checking -g -march=x86-64 -mtune=generic -O2 -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2,-D_GLIBCXX_ASSERTIONS -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -m32 -O2 -g -march=x86-64 -mtune=generic -O2 -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2,-D_GLIBCXX_ASSERTIONS -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -I. -I. -I../../.././gcc -I/build/gcc/src/gcc/libgcc -I/build/gcc/src/gcc/libgcc/. -I/build/gcc/src/gcc/libgcc/../gcc -I/build/gcc/src/gcc/libgcc/../include -I/build/gcc/src/gcc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /build/gcc/src/gcc/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS cc1: error: ‘-Wformat-security’ ignored without ‘-Wformat’ [-Werror=format-security] I am not sure how these flags are set. In any case, the second patch works around the issue by changing the --enable-build-format-warnings to add -Wno-format-security to the flags, making the flags consistent again. I think the first patch is a genuine fix, but I'm not sure about the second. I would have expected --enable-build-format-warnings to entirely remove the -Wno-format option, but it seems to stick somewhere in the build process, and I can't see where.
Created attachment 50758 [details] Workaround for -Wno-format flag injected during build process.
Comment on attachment 50757 [details] Patch to fix -Werror=format-security errors I doubt you have properly tested it, because it is clearly buggy. const char *message = (result & CPP_N_UNSIGNED) == CPP_N_UNSIGNED ? N_("use of C++23 %<size_t%> integer constant") : N_("use of C++23 %<make_signed_t<size_t>%> integer constant"); cpp_warning_with_line (pfile, CPP_W_SIZE_T_LITERALS, virtual_location, 0, message); Changing this to "%s", message obviously breaks it, it will not print use of C++23 'size_t' integer constant (or with UTF-8 quotes etc. and with colors etc.), but use of C++23 %<size_t%> integer constant
I had tested with a simple printf: #include <stdio.h> #ifndef N_ # define N_(msgid) msgid #endif int main(int argc, char* argv[]) { printf(N_("use of C++23 %<size_t%> integer constant")); printf(N_("use of C++23 %<make_signed_t<size_t>%> integer constant")); return 0; } which prints the same thing with or without the "%s" format string. I've been trying to trace where pfile->cb.diagnostic is set to see how the output is actually processed, but I haven't found it yet. Thanks for the feedback!
%< and %> are GCC diagnostics format specifiers, not printf. They are more similar to e.g. GNU printf %m , something that doesn't take any va_arg, but is interpreted. Try printf ("%m\n"); vs. printf ("%s", "%m\n"); to see the difference. Anyway, for this case either using the conditional directly in the cpp_warning_with_line argument instead of in initializer of a temporary, or two cpp_warning_with_line calls each with a separate string would do. Anyway, I strongly doubt your patch covers everything, I can see e.g. gcc/c/c-convert.c:81:31: warning: format not a string literal and no format arguments [-Wformat-security] gcc/c/c-typeck.c:3681:28: warning: format not a string literal and no format arguments [-Wformat-security] gcc/c/c-typeck.c:4433:42: warning: format not a string literal and no format arguments [-Wformat-security] gcc/c/c-typeck.c:6587:43: warning: format not a string literal and no format arguments [-Wformat-security] gcc/c/c-typeck.c:11679:42: warning: format not a string literal and no format arguments [-Wformat-security] gcc/c-family/c-common.c:6358:30: warning: format not a string literal and no format arguments [-Wformat-security] gcc/c-family/c-common.c:6362:33: warning: format not a string literal and no format arguments [-Wformat-security] gcc/fold-const.c:303:42: warning: format not a string literal and no format arguments [-Wformat-security] gcc/ipa-devirt.c:951:47: warning: format not a string literal and no format arguments [-Wformat-security] gcc/analyzer/program-state.cc:1153:20: warning: format not a string literal and no format arguments [-Wformat-security] gcc/diagnostic.c:1887:52: warning: format not a string literal and no format arguments [-Wformat-security] gcc/cp/cvt.c:725:26: warning: format not a string literal and no format arguments [-Wformat-security] gcc/cp/error.c:799:20: warning: spurious leading punctuation sequence ‘<’ in format [-Wformat-diag] gcc/cp/error.c:799:20: warning: spurious trailing punctuation sequence ‘>’ in format [-Wformat-diag] gcc/cp/error.c:799:20: warning: spurious leading punctuation sequence ‘<’ in format [-Wformat-diag] gcc/cp/error.c:799:20: warning: spurious trailing punctuation sequence ‘>’ in format [-Wformat-diag] gcc/cp/decl.c:3485:22: warning: format not a string literal and no format arguments [-Wformat-security] gcc/cp/typeck.c:4721:24: warning: format not a string literal and no format arguments [-Wformat-security] gcc/cp/typeck.c:6630:24: warning: format not a string literal and no format arguments [-Wformat-security] gcc/cp/pt.c:19640:20: warning: format not a string literal and no format arguments [-Wformat-security] gcc/collect2.c:2422:37: warning: format not a string literal and no format arguments [-Wformat-security] gcc/collect-utils.c:200:37: warning: format not a string literal and no format arguments [-Wformat-security] gcc/lto-wrapper.c:1606:31: warning: format not a string literal and no format arguments [-Wformat-security] and you've only touched the gcc/diagnostic.c case from that.
I just started looking at these other cases (for some reason I didn't see them in my initial compilation), but I am not sure what format specifiers should be used. Are the format specifiers used by __gcc_tdiag__ documented somewhere? I tried grepping through the source, but couldn't find anything.