linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
Cc: Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH] x86/syscalls: Mark expected switch fall-throughs
Date: Tue, 28 Nov 2017 19:35:59 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1711281933170.2222@nanos> (raw)
In-Reply-To: <alpine.DEB.2.20.1711281924080.2222@nanos>

On Tue, 28 Nov 2017, Thomas Gleixner wrote:

> On Tue, 28 Nov 2017, Gustavo A. R. Silva wrote:
> > Quoting Thomas Gleixner <tglx@linutronix.de>:
> > > > 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.
> 
> It's not about ugly. It's about _USEFULL_.
> 
> The comments are ugly AND completely useless for the compiler and they are
> going to be malformatted so checker tools can't differentiate the false
> positives.
> 
> The macro, in which more or less ugly form written, is both documentation
> and helps the compiler NOT to emit the same crap over and over.

Just checked and GCC really supports analyzing the comment to some extent.

But just look at

    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77817

 " It is not really possible.  __attribute__((fallthrough)) has precise
   rules on where it can appear, while /* FALLTHRU */ comments, being
   comments, can appear anywhere.  Especially with -Wimplicit-fallthrough=1
   when all comments are considered fallthru comments... "

I have no idea who came up with that brilliant idea of parsing comments in
the code. It's so simple to make this parser completely fail that it's not
even funny anymore.

I don't care what other people prefer. The code base I'm responsible for
gets either proper annotations or nothing.

Thanks,

	tglx

  reply	other threads:[~2017-11-28 18:36 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-27 23:52 [PATCH] x86/syscalls: Mark expected switch fall-throughs 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
2017-11-28 18:27           ` Thomas Gleixner
2017-11-28 18:35             ` Thomas Gleixner [this message]
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=alpine.DEB.2.20.1711281933170.2222@nanos \
    --to=tglx@linutronix.de \
    --cc=garsilva@embeddedor.com \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=x86@kernel.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).