On 8/6/22 8:12 AM, Chris Angelico wrote:
On Sat, 6 Aug 2022 at 22:08, Richard Damon <rich...@damon-family.org> wrote:
On 8/6/22 12:01 AM, Chris Angelico wrote:
On Sat, 6 Aug 2022 at 13:54, Dan Stromberg <drsali...@gmail.com> wrote:
On Fri, Aug 5, 2022 at 12:54 PM Grant Edwards <grant.b.edwa...@gmail.com>
wrote:
In C, this doesn't do what it looks like it's supposed to do.
if (foo)
do_this();
and_this();
then_do_this();
It's been quite a while since I used C, but with the right compiler
flag(s), I think this may be a thing of the past when compiling with gcc:
https://developers.redhat.com/blog/2016/02/26/gcc-6-wmisleading-indentation-vs-goto-fail
Ah yes, because compiler warnings are always viewed and acted upon.
Have you ever watched the compilation of a large open-source project,
done using the project's own build system and therefore the team's
preferred warning settings? It's normal to have such a spew of
warnings that you can't find anything interesting, or to have new
warnings in new versions of GCC be utterly useless for the same
reason.
ChrisA
You make it so you HAVE to fix the warning by adding the option to make
warnings into errors.
This does mean that you need to fix all the warnings that don't actually
mean anything,
Good code shouldn't generate many warnings, either you have warnings
enabled that you don't care about, or your code is doing things you have
told the complier you shouldn't do.
I say again: have you ever watched the compilation of a large
open-source project? You cannot turn warnings into errors, because
there are ALWAYS warnings. Maybe, once upon a time, the policy was to
ensure that there were no warnings on any major compiler; but times
change, compilers add new warnings, new compilers join the club, and
it becomes practically impossible to prevent warnings. Which, in turn,
makes all warnings basically meaningless.
Hmm. I don't think I've ever compiled gcc from source. Maybe I should
do that, just to see whether gcc itself compiles with no warnings
under gcc.
ChrisA
And for any project, that is a choice THEY made.
For projects where code quality is actually a defined metric, there is
normally a specified warning level (for a specified set of compilers and
versions) that the code needs to compile at least nearly clean at.
Yes, you can get that ton of warnings when at a higher warning level,
but that is why you specify the warning level to use, and put the
specific mitigations/suppressions for the few cases where the code is
correct, but generates that warning.
Yes, you can get a lot of warnings with another compiler, but that is
because you aren't running at the correct warning level for that
compiler, which is why the set of compilers that you are "warning free"
on is specified. When you add a new compiler, it may first not be
warning free until you make the effort (if you ever do) to make it
warning free for that.
Major open source projects will have a "toll gate" on the official
repository that checks that additions keep the code to the standard it
has established,
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
