From: "Bjørn Mork" <bjorn@mork.no>
To: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
Cc: Johan Hovold <johan@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] USB: serial: io_edgeport: mark expected switch fall-throughs
Date: Sat, 28 Oct 2017 12:56:51 +0200 [thread overview]
Message-ID: <87k1zf4k24.fsf@miraculix.mork.no> (raw)
In-Reply-To: <20171027203906.GA7054@embeddedor.com> (Gustavo A. R. Silva's message of "Fri, 27 Oct 2017 15:39:06 -0500")
"Gustavo A. R. Silva" <garsilva@embeddedor.com> writes:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Notice that in this particular case I replaced "...drop on through"
> comments with a proper "fall through" comment on its own line, which
> is what GCC is expecting to find.
Sounds to me like GCC is the wrong tool for this. But I would of course
not mind if it was *just* the text. However, as your patch cleary
shows, the simplified logic leads to real problems:
> @@ -1819,8 +1819,8 @@ static void process_rcvd_data(struct edgeport_serial *edge_serial,
> edge_serial->rxState = EXPECT_DATA;
> break;
> }
> - /* Else, drop through */
> }
> + /* fall through */
> case EXPECT_DATA: /* Expect data */
> if (bufferLength < edge_serial->rxBytesRemaining) {
> rxLen = bufferLength;
The original comment clearly marked a *conditional* fall through at the
correct place. Your patch makes it appear as if there is an
unconditional fall through here. There is not. The fallthrough only
applies to one of a number of nested if blocks. There are no less than
3 break statements in the same case block.
Not a big deal maybe, just as the lack of any "fall through" comment
isn't a big deal in the first place. But this change is clearly making
this code harder to read, and the change is therefore harmful IMHO.
If you can't make -Wimplicit-fallthrough work without removing such
precise fallthrough markings, then my proposal is to drop it and use
some other tool.
Bjørn
next prev parent reply other threads:[~2017-10-28 10:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-27 20:39 Gustavo A. R. Silva
2017-10-28 10:56 ` Bjørn Mork [this message]
2017-10-28 23:47 ` Gustavo A. R. Silva
2017-10-30 11:54 ` David Laight
2017-10-30 14:42 ` Johan Hovold
2017-10-31 4:50 ` Gustavo A. R. Silva
2017-10-31 7:49 ` Johan Hovold
2018-06-28 18:40 Gustavo A. R. Silva
2018-07-02 8:51 ` Johan Hovold
2018-07-02 13:00 ` Gustavo A. R. Silva
2018-07-02 15:16 ` Johan Hovold
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=87k1zf4k24.fsf@miraculix.mork.no \
--to=bjorn@mork.no \
--cc=garsilva@embeddedor.com \
--cc=gregkh@linuxfoundation.org \
--cc=johan@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.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
all inboxes | Powered by JetHome®