Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build: add -Wimplicit-fallthrough #14561

Merged
merged 1 commit into from
Oct 13, 2023

Conversation

idryzhov
Copy link
Contributor

There are currently no cases of implicit fallthrough in FRR. Adding this to be safe in the future.

@donaldsharp
Copy link
Member

once ci finishes I'll push this in

@idryzhov
Copy link
Contributor Author

Wow that's interesting. It looks like we actually have some implicit fallthrough but only OpenBSD build catches them. I tested locally on Ubuntu 20.04 and didn't see the errors. CI doesn't have errors on Ubuntu as well...
I'll look into it tomorrow.

@donaldsharp
Copy link
Member

clang-15 reproduces this problem for me on my build machine

@idryzhov idryzhov force-pushed the implicit-fallthrough branch from cb5ee0a to 87f65e1 Compare October 11, 2023 23:05
@github-actions github-actions bot added size/L and removed size/XS labels Oct 11, 2023
@idryzhov
Copy link
Contributor Author

So yes, OpenBSD uses clang as a compiler and there were two problems with the current code:

  1. /* fallthrough */-like comments are not portable as they are not supported by clang. I replaced all the comments with portable fallthrough; pseudo-keyword defined in compiler.h. It was already defined as _FALLTHROUGH; but I renamed it because our doc recommends fallthrough; and Kernel uses it as well.
  2. clang doesn't allow the following:
    case X:
        do_something();
    default:
        break;
    
    I added explicit break; statements to affected places.

Copy link
Member

@ton31337 ton31337 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@@ -229,7 +229,7 @@ send_capability(struct nbr *nbr, uint16_t capability, int enable)
* Announcement Parameter in Capability messages sent to
* its peers".
*/
/* FALLTHROUGH */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I disagree that this should be a fallthrough to the below message. The message seems wrong to me.

@@ -333,7 +333,7 @@ recv_capability(struct nbr *nbr, char *buf, uint16_t len)
* parameter and process any other Capability Parameters
* in the message".
*/
/* FALLTHROUGH */
fallthrough;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

again the actions taken in the default seem to be off to me.

@donaldsharp
Copy link
Member

Mark, Igor and myself spoke in slack and had this conversation:

a) This changes exposes some problems in the code from my perspective, but it is not Igor's fault for this exposure and as such should not be punished
b) The choice of a fallthrough was fundamentally wrong in more than a few places in the current code base. Some of these are extremely obvious how to fix and some are not.
c) How can we capture these and come back and fix them in the future?

Igor has agreed to go through and fix the easy ones. The harder ones I am tracking down the original implementer and asking them to fix them problems.

The easy one's should not be too much of a problem to go through and fix, all three of us have seen changes that need to be made and Igor should be positioning these changes soon.

Let's hold off pushing this in until Igor updates the PR again.

Also:
- replace all /* fallthrough */ comments with portable fallthrough;
pseudo keyword to accomodate both gcc and clang
- add missing break; statements as required by older versions of gcc
- cleanup some code to remove unnecessary fallthrough

Signed-off-by: Igor Ryzhov <[email protected]>
@idryzhov idryzhov force-pushed the implicit-fallthrough branch from 87f65e1 to 7d67b9f Compare October 12, 2023 18:29
@idryzhov
Copy link
Contributor Author

I cleaned up all places where the use of fallthrough; was not necessary/made the code more complex. The remaining question is whether fallthrough usage is correct in LDPD and NHRPD. Waiting the original implementer to confirm.

@donaldsharp donaldsharp merged commit 02cbd97 into FRRouting:master Oct 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants