Bruno Haible <br...@clisp.org> writes: > You are supposed to choose the warnings that are reasonable for your > project. For some project of mine, I had to disable 20-40 warning options > before I could get reasonable output.
That's exactly what I did :-) The set of warnings enabled in those commands is the subset of warnings for which my project compiles warning-free for that compiler on the different architectures I test. Or at least it used to be warning free before I attempted to upgrade its gnulib directory. I have configure checks to detect which warning I can enable depending on the compiler, and disable some warnings in version of GCC where they are bogus. I've done these extreme warnings on this project since 2003, but only on my development builds, so I can detect and fix any new concerns brought up by newer compiler versions. Of course users builds are not done with those options. Obviously I target a much smaller and more modern set of systems than gnulib, so I perfectly understand that you may not want to fix all warnings. >> > ../lib/gettext.h:234:22: error: zero as null pointer constant >> > [-Werror,-Wzero-as-null-pointer-constant] >> > if (msg_ctxt_id != NULL) >> > ^~~~ > > This will not be changed. I have another related suggestion. My code is not internationalized. gettext.h got pulled in because some modules like argp are internationalized, but ENABLE_NLS will never be defined in my project. So this above warning is about code that will never be used, but for which the compiler is still wasting resources for parsing and analyzing. Would it be acceptable to replace all these pgettext functions by dummy macros when NLS is disabled? -- Alexandre Duret-Lutz
