[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4014118b-90a6-68c5-048f-32485fa3e852@web.de>
Date: Tue, 23 Jun 2020 08:12:39 +0200
From: Markus Elfring <Markus.Elfring@....de>
To: Denis Efremov <efremov@...ux.com>,
Coccinelle <cocci@...teme.lip6.fr>,
Gilles Muller <Gilles.Muller@...6.fr>,
Julia Lawall <julia.lawall@...ia.fr>,
Masahiro Yamada <yamada.masahiro@...ionext.com>,
Michal Marek <michal.lkml@...kovi.net>,
Nicolas Palix <nicolas.palix@...g.fr>
Cc: linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org,
"Gustavo A. R. Silva" <garsilva@...eddedor.com>,
Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH v4] coccinelle: misc: add array_size_dup script to detect
missed overflow checks
> Changes in v2:
…
> - assignment operator used
I prefer the distinction for the application of corresponding metavariables.
> Changes in v3:
…
> - \(&E1\|&E2\) changed to &\(E1\|E2\)
Would it be more helpful to mention the movement of the ampersand
before SmPL disjunctions?
…
>+/// Three types of patterns for these functions:
Will another adjustment be needed according to your information “duplicates warning removed”?
…
> +virtual context
> +virtual report
> +virtual org
Can the following SmPL code variant ever become more attractive?
+virtual context, report, org
…
> +expression subE1 <= as.E1;
> +expression subE2 <= as.E2;
> +expression as.E1, as.E2, E3;
How do you think about the following SmPL code variant?
+expression subE1 <= as.E1,
+ subE2 <= as.E2,
+ as.E1, as.E2, E3;
…
> +msg = "WARNING: array_size is used later (line %s) to compute the same size" % (p2[0].line)
> +coccilib.report.print_report(p1[0], msg)
Please omit the extra Python variable “msg” for the passing of such simple message objects.
What does hinder you to take the proposed script variants better into account?
Regards,
Markus
Powered by blists - more mailing lists