Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Concatenated if and preprocessor Date: Sat, 15 Mar 2025 08:49:25 -0700 Organization: A noiseless patient Spider Lines: 43 Message-ID: <86y0x6qooq.fsf@linuxsc.com> References: <86frjfsgtb.fsf@linuxsc.com> <86bju3s5vp.fsf@linuxsc.com> <87zfhniaij.fsf@nosuchdomain.example.com> <8634ffrzj0.fsf@linuxsc.com> <87o6y3i45x.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Sat, 15 Mar 2025 16:49:27 +0100 (CET) Injection-Info: dont-email.me; posting-host="3e46727b472ba2d5903adccba45d2adf"; logging-data="3913750"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+xeQqdXIXaqUyKog0fGJmJlOqJ63bcHkk=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:cvfQTJxqoCq5U7eHc6cJ93juFbY= sha1:ff1GMEamxWAmcaag64DobzEDhFE= Xref: csiph.com comp.lang.c:391240 scott@slp53.sl.home (Scott Lurndal) writes: > Keith Thompson writes: > >> Tim Rentsch writes: >> >>> Keith Thompson writes: >>> >>>> Tim Rentsch writes: >>>> >>>>> It's because of examples like this that I am wary of rules >>>>> like "enable all warnings" and "treat any warning condition >>>>> as an error." I recently ran across a set of coding standard >>>>> rules that included these rules: not just /some/ warning >>>>> conditions, but ALL warning conditions. I still don't know >>>>> if they were literally serious. (And my understanding is >>>>> clang has a -Weverything option, which enables all warning >>>>> conditions that clang is able to test for, no matter how >>>>> silly.) >>>> >>>> I've worked under such coding standards. >>> >>> I'm guessing this comment is an overstatement, and that you have >>> worked with similar but not nearly as stringent coding standards. >>> The coding standard I was referring to above says "Compile with >>> all possible warnings active" (and then also says something about >>> addressing them). >> >> Right, I didn't read closely enough. Some (non-maximal) set of >> warnings were enabled, and any warnings that resulted were treated >> as fatal errors. > > We build with -Wall. It's been quite successful for us and > hasn't resulted in significant effort to maintain (granted > as we switch to newer versions of the compiler suite, we > run into new warnings, but they're quite easy to address > either via code changes or #pragma). > > The codebase runs well over two million SLOC and supports > gcc7 through gcc14. Can you say which new warnings have been addressed via #pragma (which I assume effectively means selective disabling)?