Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Abstract Syntax Tree for C programs Date: Thu, 06 Jun 2019 23:26:53 -0700 Organization: A noiseless patient Spider Lines: 38 Message-ID: <861s05ap1u.fsf@mailhub.linuxsc.com> References: <475067fe-369c-4246-84a1-05b1a3a0c6be@googlegroups.com> <5dd4672f-a571-40bc-bb1a-c14f6c631eb7@googlegroups.com> <5cf589ea$0$3377$426a34cc@news.free.fr> <5cf62fb7$0$19246$426a34cc@news.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="745a774da000a5ca79d2c1f918b03fc4"; logging-data="3907"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18c9gILIyGt967QSo8zKZaTFTofbSVRCSo=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:hFXBpBuyS1CjKxStl6OqS5llfOM= sha1:dlV9hMBmQZf+GGKr/0HfEedA8Io= Xref: csiph.com comp.lang.c:144564 Mateusz Viste writes: > On Tue, 04 Jun 2019 08:54:39 +0200, David Brown wrote: >[...] > >> clang's "-Weverything" is for testing only - it is not intended >> for use in real code. Pretty much no one writes real code that >> is warning-free with /all/ gcc or clang warnings enabled, as many >> of them are stylistic choices rather than indications of errors >> in the code. Agree 100% on the "stylistic choices" characterization. > I, for one, use -Weverything for real, production code. It's true > that it may be frustrating at first, but at the same time it > enforces good and consistent coding practices (and it "builds > character", too, as Bill Watterson would say). [...] Better: All regular compiles, including production compiles, should be limited to just those conditions that are virtually guaranteed to be errors (or agreed to be treated as errors even if they might not be). Ensure they are treated as such by using -Werror. The conditions tested should be stable (so they should never include options like -Wall or -Wextra). Every so often, run an extra compilation with warning levels cranked up, and review the set of flagged cases. Any bugs found should of course be corrected, but other cases may be left unchanged, as may be thought appropriate in each particular case. IME this approach gives better results than using maximum warning settings all the time. On the last part: the idea that all the stylistic diagnostics lead to good coding practices is, well, let me say suspect. Some of them, maybe; others not so much, and for some even counter-productive. They should never be adopted wholesale just because a compiler lumps them all together under a single option or two.