[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171128143714.Horde.2uPOfQfKWjP7aGfH2w0lflN@gator4166.hostgator.com>
Date: Tue, 28 Nov 2017 14:37:14 -0600
From: "Gustavo A. R. Silva" <garsilva@...eddedor.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Alan Cox <gnomes@...rguk.ukuu.org.uk>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
the arch/x86 maintainers <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH] x86/syscalls: Mark expected switch fall-throughs
Quoting Linus Torvalds <torvalds@...ux-foundation.org>:
> On Tue, Nov 28, 2017 at 11:00 AM, Alan Cox
> <gnomes@...rguk.ukuu.org.uk> wrote:
>>
>> The notation in question has been standard in tools like lint since the
>> end of the 1970s
>
> Yes.
>
> That said, maybe one option would be to annotate the "case:" and
> "default:" statements if that makes people happier.
>
> IOW, we could do something like
>
> #define fallthrough __atttibute__((fallthrough))
>
> and then write
>
> fallthrough case 1:
> ...
>
> which while absolutely not traditional, might look and read a bit more
> logical to people. I mean, it literally _is_ a "fallthrough case", so
> it makes semantic sense.
>
This is elegant. The thing is that this makes it appear as if there is
an unconditional fall through.
It is not uncommon to have multiple break statements in the same case
block and to fall through also.
Thanks
--
Gustavo A. R. Silva
Powered by blists - more mailing lists