41–50 of 117 posts
-Wno-parentheses
Also, speaking of flags, I'm personally in love with -MMD. It makes dependency generation pretty painless.
This is probably an unpopular opinion, but: -Werror is fine on your dev machine, but is a very bad idea in the official build system, notably if you do it for a library that you want people to use. As soon as you want to compile with various compilers, systems, use cross-compilation and other funny things that makes it portable, you're going to have a bad time. New compilers will make new warnings, old compilers will…
Our experience is that it is actually an excellent sanitary decision. We are using multiple builders with fixed GCC releases (for RHEL5, RHEL6 etc. flavors), and yes it means fixing additional warnings when we have to introduce a new architecture. But I can not count the number of serious issues we avoided by spotting and investigating warnings.
Especially when you have ASM code or complex arithmetic, and when you allow to compile for different versions of Windows...
It's a good idea to have it on your build-farm, to track bugs, but it is not OK on your shipping build.
-Wall -Wextra -pedantic-errors -funroll-loops.info -Weffc++ -Wunreachable-code -fno-exceptions -03 -WerrorVery surprising to not see the -std option to actually clarify which language standard is being used. Perhaps that isn't as important in C++ as it is in C.
Very surprising to not see the -std option to actually clarify which language standard is being used. Perhaps that isn't as important in C++ as it is in C.
"-Winit-self" actually disables the common "var x = x" idiom which is used to silence "uninitialized variable" warnings. Personally I consider "-Werror" stupid. Warnings are designed to help and be reviewed, but aiming at "100% warning free" code should not be an "aim". For instance, I'd rather have "unitialized warnings" than use "i = i", which you know, might actually be correct code if "i" was available in scope a…
-g -g3 -ggdb -gdwarf-4
(gdb) info macro Py_TYPE
Defined at Include/object.h:117
included at Include/pytime.h:6
included at Include/Python.h:65
included at Parser/myreadline.c:12
#define Py_TYPE(ob) (((PyObject*)(ob))->ob_type)"-Winit-self" actually disables the common "var x = x" idiom which is used to silence "uninitialized variable" warnings. Personally I consider "-Werror" stupid. Warnings are designed to help and be reviewed, but aiming at "100% warning free" code should not be an "aim". For instance, I'd rather have "unitialized warnings" than use "i = i", which you know, might actually be correct code if "i" was available in scope a…
-Werror is debatable. On a controlled build environment (with fixed GCC version and fixed distribution), I am convinced this is the way to go. After careful reviews, -Wno-xxx switches can be added on demand (such as -Wno-overlength-strings, haha) to limit annoying/irrelevant messages, but experience shows that having thousands of warnings in logs lead to ignore issues (this is especially true when the codebase is hug…
In my mind it's way better to just build your software with -Wall/others and implicitly review all warnings before pushing changed files to a common repository (which is kind of obvious, since when you are developing you also are looking the build logs).
For instance, -Wunused-args is helpful, but for a provisional API that's going to stay in the repository for a couple of weeks the warning is useless. Some people would go on and add useless code to silence the warning, though I will just commit the code.
I never had in my career large projects with more than a handful of warnings anyway. The kind of person that would use -Werror, in reality would go perfectly fine without.
"-Winit-self" actually disables the common "var x = x" idiom which is used to silence "uninitialized variable" warnings. Personally I consider "-Werror" stupid. Warnings are designed to help and be reviewed, but aiming at "100% warning free" code should not be an "aim". For instance, I'd rather have "unitialized warnings" than use "i = i", which you know, might actually be correct code if "i" was available in scope a…
> "-Winit-self" actually disables the common "var x = x" idiom which is used to silence "uninitialized variable" warnings. so now we have a flag that disables a hack in code that is used to disable a warning caused by another flag. This is about as ridiculous to my (untrained in C) mind as it is to have -Wall not in-fact turn on all warnings.
Take assignment/evaluation in a condition:
if(a = [expr])
The list goes on and on. In fact, the level of diagnostics that you get in C is pretty bit, and probably one of the best in class compared to any other language thanks to the maturity of the toolchain.
I go overkill on the debugger flags: -g -g3 -ggdb -gdwarf-4 Being able to debug C-macros has improved my life! (gdb) info macro Py_TYPE Defined at Include/object.h:117 included at Include/pytime.h:6 included at Include/Python.h:65 included at Parser/myreadline.c:12 #define Py_TYPE(ob) (((PyObject*)(ob))->ob_type)