Re: Trying to understand nested loops
On 8/6/22 12:01 AM, Chris Angelico wrote: On Sat, 6 Aug 2022 at 13:54, Dan Stromberg wrote: On Fri, Aug 5, 2022 at 12:54 PM Grant Edwards 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. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Trying to understand nested loops
On Sat, 6 Aug 2022 at 22:08, Richard Damon wrote: > > On 8/6/22 12:01 AM, Chris Angelico wrote: > > On Sat, 6 Aug 2022 at 13:54, Dan Stromberg wrote: > >> On Fri, Aug 5, 2022 at 12:54 PM Grant Edwards > >> 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Trying to understand nested loops
On 8/6/22 8:12 AM, Chris Angelico wrote: On Sat, 6 Aug 2022 at 22:08, Richard Damon wrote: On 8/6/22 12:01 AM, Chris Angelico wrote: On Sat, 6 Aug 2022 at 13:54, Dan Stromberg wrote: On Fri, Aug 5, 2022 at 12:54 PM Grant Edwards 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
Re: Trying to understand nested loops
On Sat, 6 Aug 2022 at 22:39, Richard Damon wrote: > > On 8/6/22 8:12 AM, Chris Angelico wrote: > > On Sat, 6 Aug 2022 at 22:08, Richard Damon wrote: > >> On 8/6/22 12:01 AM, Chris Angelico wrote: > >>> On Sat, 6 Aug 2022 at 13:54, Dan Stromberg wrote: > On Fri, Aug 5, 2022 at 12:54 PM Grant Edwards > 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 -- https://mail.python.org/mailman/listinfo/python-list
RE: Trying to understand nested loops
This reminds me a bit of how routine spelling checkers and often especially grammar checkers, generate so many suggestions about mistakes as to become ignored. If you are writing using lots of names and jargon that keep getting flagged as errors and they are spelled or used exactly as you want, then it gets to be too annoying and you turn off the feature. Yes, you can sometimes silence some things in a spell checker that allows you to add words to a custom dictionary but for now, that dictionary is not known to every application that checks your spelling. That can be the nature of the beast. If your compiler decides to warn you every time you do a division that you might be dividing by zero because you do not perform the test right before that, then you end up with code that tests it AGAIN after having arranged for the value to never be zero in the first place, then test it again when you divide something else by it, ... I am sure some programming language has some kind of pragma that lets you whisper to the compiler that this variable at this time is guaranteed not to be zero, or that the region is in a try/catch zone which will intercept and fix the results of a divide by zero error. Just an example. And as you say, new or improved compilers can be made to be ever more picky about trying to find possible anomalies. Things are useful when they are somewhat manageable. If a compiler things it detects 372 places in your code where the same thing needs to be mentioned, such as reserving space for an object without simultaneously filling it with some contents, then it would be nice if instead of printing ALL of them, it consolidated it into one warning and say you can click on something to see the 372 instances. -Original Message- From: Python-list On Behalf Of Chris Angelico Sent: Saturday, August 6, 2022 8:12 AM To: [email protected] Subject: Re: Trying to understand nested loops On Sat, 6 Aug 2022 at 22:08, Richard Damon wrote: > > On 8/6/22 12:01 AM, Chris Angelico wrote: > > On Sat, 6 Aug 2022 at 13:54, Dan Stromberg wrote: > >> On Fri, Aug 5, 2022 at 12:54 PM Grant Edwards > >> > >> 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-ind > >> entation-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 -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
