lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200220162114.138f976ae16a5e58e13a51ae@linux-foundation.org>
Date:   Thu, 20 Feb 2020 16:21:14 -0800
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Joe Perches <joe@...ches.com>
Cc:     linux-kernel@...r.kernel.org, clang-built-linux@...glegroups.com
Subject: Re: [PATCH] cvt_fallthrough: A tool to convert /* fallthrough */
 comments to fallthrough;

On Thu, 20 Feb 2020 12:30:21 -0800 Joe Perches <joe@...ches.com> wrote:

> Convert /* fallthrough */ style comments to the pseudo-keyword fallthrough
> to allow clang 10 and higher to work at finding missing fallthroughs too.
> 
> Requires a git repository and overwrites the input files.
> 
> Typical command use:
>     ./scripts/cvt_fallthrough.pl <path|file>
> 
> i.e.:
> 
>    $ ./scripts/cvt_fallthrough.pl block
>      converts all files in block and its subdirectories
>    $ ./scripts/cvt_fallthrough.pl drivers/net/wireless/zydas/zd1201.c
>      converts a single file
> 
> A fallthrough comment with additional comments is converted akin to:
> 
> -		/* fall through - maybe userspace knows this conn_id. */
> +		fallthrough;    /* maybe userspace knows this conn_id */
> 
> A fallthrough comment or fallthrough; between successive case statements
> is deleted.
> 
> e.g.:
> 
>     case FOO:
>     	/* fallthrough */ (or fallthrough;)
>     case BAR:
> 
> is converted to:
> 
>     case FOO:
>     case BAR:
> 
> Signed-off-by: Joe Perches <joe@...ches.com>
> ---
>  scripts/cvt_fallthrough.pl | 215 +++++++++++++++++++++++++++++++++++++

Do we need this in the tree long-term?  Or is it a matters of "hey
Linus, please run this" then something like add a checkpatch rule to
catch future slipups?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ