Trying to understand nested loops

Chris Angelico rosuav at gmail.com
Sat Aug 6 08:46:27 EDT 2022


On Sat, 6 Aug 2022 at 22:39, Richard Damon <Richard at damon-family.org> wrote:
>
> On 8/6/22 8:12 AM, Chris Angelico wrote:
> > On Sat, 6 Aug 2022 at 22:08, Richard Damon <Richard at damon-family.org> wrote:
> >> On 8/6/22 12:01 AM, Chris Angelico wrote:
> >>> On Sat, 6 Aug 2022 at 13:54, Dan Stromberg <drsalists at gmail.com> wrote:
> >>>> On Fri, Aug 5, 2022 at 12:54 PM Grant Edwards <grant.b.edwards at 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.

Indeed. So you can't really say "good code shouldn't generate many
warnings" unless (a) you're saying that lots of projects are made up
of bad code, or (b) your statement that this is "a thing of the past"
is flat-out false, because it can only be valid if you assume that
everyone has that warning enabled, and preferably set to be an error.

So, for the vast majority of projects out there, indentation errors
are going to continue to go uncaught by C compilers. It's not "a thing
of the past" until most projects use the flag, and preferably, the
flag becomes active by default.

And for the record, I have seen spurious warnings from *that exact
flag* in a large project (an image parsing library). Spurious in that
the code was actually correct, despite the compiler warning about it.

ChrisA


More information about the Python-list mailing list