From: "Gustavo A. R. Silva" <email@example.com> To: Thomas Gleixner <firstname.lastname@example.org> Cc: Ingo Molnar <email@example.com>, "H. Peter Anvin" <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, Kees Cook <email@example.com> Subject: Re: [PATCH] x86/syscalls: Mark expected switch fall-throughs Date: Tue, 28 Nov 2017 12:22:35 -0600 [thread overview] Message-ID: <20171128122235.Horde.vFP-9ZfAP0f9BFNePB8Z8xi@gator4166.hostgator.com> (raw) In-Reply-To: <alpine.DEB.2.20.1711281911280.2222@nanos> Quoting Thomas Gleixner <firstname.lastname@example.org>: > On Tue, 28 Nov 2017, Thomas Gleixner wrote: >> On Tue, 28 Nov 2017, Gustavo A. R. Silva wrote: >> > Quoting Thomas Gleixner <email@example.com>: >> > >> > > On Mon, 27 Nov 2017, Gustavo A. R. Silva wrote: >> > > >> > > > In preparation to enabling -Wimplicit-fallthrough, mark switch cases >> > > > where we are expecting to fall through. >> > > >> > > > case 0: >> > > > if (!n--) break; >> > > > *args++ = regs->bx; >> > > > + /* fall through */ >> > > >> > > And these gazillions of pointless comments help enabling of >> > > -Wimplicit-fallthrough in which way? >> > > >> > >> > The -Wimplicit-fallthrough option was added to GCC 7. We want to add that >> > option to the top-level Makefile so we can have the compiler help >> us not make >> > mistakes as missing "break"s or "continue"s. This also documents >> the intention >> > for humans and provides a way for analyzers to report issues or >> ignore False >> > Positives. >> > >> > So prior to adding such option to the Makefile, we have to >> properly add a code >> > comment wherever the code is intended to fall through. >> > >> > During the process of placing these comments I have identified actual bugs >> > (missing "break"s/"continue"s) in a variety of components in the >> kernel, so I >> > think this effort is valuable. Lastly, such a simple comment in >> the code can >> > save a person plenty of time during a code review. >> >> To be honest, such comments annoy me during a code review especially when >> the fallthrough is so obvious as in this case. There might be cases where >> its worth to document because it's non obvious, but documenting the obvious >> just for the sake of documenting it is just wrong. > I understand that and I agree that in this particular case it is just obvious. The thing is that if we want to benefit from having the compiler help us to spot these kind of issues before committing our code, we have to address every place in the whole code-base. > And _IF_ at all then you want a fixed macro for this and not a comment > which will be formatted as people see it fit. > > GCC supports: __attribute__ ((fallthrough)) which we can wrap into a macro, > e.g. falltrough() > > That'd be useful, but adding all these comments and then having to chase a > gazillion of warning instances to figure out whether there is a comment or > not is just backwards. > I have run into this before and people find what you suggest even uglier. Thanks -- Gustavo A. R. Silva
next prev parent reply other threads:[~2017-11-28 18:22 UTC|newest] Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-11-27 23:52 Gustavo A. R. Silva 2017-11-28 13:49 ` Thomas Gleixner 2017-11-28 18:05 ` Gustavo A. R. Silva 2017-11-28 18:10 ` Thomas Gleixner 2017-11-28 18:17 ` Thomas Gleixner 2017-11-28 18:22 ` Gustavo A. R. Silva [this message] 2017-11-28 18:27 ` Thomas Gleixner 2017-11-28 18:35 ` Thomas Gleixner 2017-11-28 18:45 ` Thomas Gleixner 2017-11-28 18:53 ` Gustavo A. R. Silva 2017-11-28 19:48 ` Thomas Gleixner 2017-11-28 19:00 ` Alan Cox 2017-11-28 19:10 ` Linus Torvalds 2017-11-28 19:59 ` Joe Perches 2017-11-28 20:08 ` Thomas Gleixner 2017-11-28 20:34 ` Kees Cook 2017-11-28 20:37 ` Gustavo A. R. Silva 2017-11-29 1:07 ` Joe Perches 2017-11-29 8:20 ` Geert Uytterhoeven 2017-11-28 20:11 ` Thomas Gleixner 2017-11-28 20:25 ` Gustavo A. R. Silva 2017-11-28 21:25 ` Thomas Gleixner 2017-11-29 15:10 ` Gustavo A. R. Silva 2017-11-29 15:14 ` Thomas Gleixner 2017-11-30 0:21 ` Kees Cook 2019-01-29 23:56 Gustavo A. R. Silva 2019-01-30 0:14 ` Thomas Gleixner
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20171128122235.Horde.vFP-9ZfAP0f9BFNePB8Z8xi@gator4166.hostgator.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH] x86/syscalls: Mark expected switch fall-throughs' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).