On Wed, Oct 19, 2016 at 03:39:53PM +0200, Jean-Marc Lasgouttes wrote: > Le 19/10/2016 à 15:09, Enrico Forestieri a écrit : > >Just checked and discovered that my building script has a --disable-warnigs > >set as an unmodifiable read-only variable ;-) > > No warnings, no trouble :)
;-) > Why do you disable them, BTW? The build is quite clean these days (some > warnings are disabled by hand in autoconf). This is historical. Many years ago the sources were triggering many unavoidable warnings on cygwin, where also concept checks could not be used. So, I started to disable warnings in the build script without any ill effects, and even forgot that I was doing that... Almost same story on solaris, where I was initially using --no-this-warning type of switches (for strange kind of exotic cases that I now not even remember about but that were also unavoidable). Then, some other warning of this kind was popping out and the list of --no-this-warning switches was growing so much that I now use --disable-warnings there, too. When you are flooded with useless and unavoidable warnings, you start not paying attention to them and thus can also miss important ones. This defeats the purpose of having them enabled. > I do not know whether we can manage to create this handful of math hull > properties that cover most switch()es we may have, but it would give better > semantics to our code. Rather than « I spend 20 minutes looking at all > cases, this is the list in this case ». Yes, I understand. However, this is also something that can be done (or even is best done) later, when everything settles down. For example, this kind of classification is most probably not going to be necessary. > The best virtue of these lengthy switches is to entice to think about ways > to avoid them... Maybe. -- Enrico
