| Message ID | 1493928654-18768-7-git-send-email-Julia.Lawall@lip6.fr (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, May 04, 2017 at 10:10:51PM +0200, Julia Lawall wrote: > Drop static on a local variable, when the variable is initialized before > any use, on every possible execution path through the function. When sending a bunch of changes like this please either send the cover letter to everyone or send each patch separately (this seems like it stands alone just fine). The first question when only one patch in a series is visible is always what are the interdependencies.
On Sun, 14 May 2017, Mark Brown wrote: > On Thu, May 04, 2017 at 10:10:51PM +0200, Julia Lawall wrote: > > Drop static on a local variable, when the variable is initialized before > > any use, on every possible execution path through the function. > > When sending a bunch of changes like this please either send the cover > letter to everyone or send each patch separately (this seems like it > stands alone just fine). The first question when only one patch in a > series is visible is always what are the interdependencies. Not sure what is best to do. If the cover letter goes to everyone, it could be rejected for too many recipients. Currently it goes to all the mailing lists. If the patches are sent separately, then could there be a cover letter for each one? If the semantic patch is complicated, then I typically put the whole thing there, and an abbreviated one in the actual patch. That is not relevant here, because the semantic patch is small. Part of the purpose of the cover letter was to allow people who were not interested to skip over the whole thing at once. julia -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, May 15, 2017 at 06:41:41PM +0800, Julia Lawall wrote: > mailing lists. If the patches are sent separately, then could there be a > cover letter for each one? If the semantic patch is complicated, then I > typically put the whole thing there, and an abbreviated one in the actual > patch. That is not relevant here, because the semantic patch is small. Well, if the cover letter is needed to understand the patch then it needs to go to everyone anyway... > Part of the purpose of the cover letter was to allow people who were not > interested to skip over the whole thing at once. On the flip side things that lack context can get discarded easily.
diff --git a/drivers/regulator/palmas-regulator.c b/drivers/regulator/palmas-regulator.c index 31ae5ee..34d4a62 100644 --- a/drivers/regulator/palmas-regulator.c +++ b/drivers/regulator/palmas-regulator.c @@ -1491,7 +1491,7 @@ static int palmas_dt_to_pdata(struct device *dev, } for (idx = 0; idx < ddata->max_reg; idx++) { - static struct of_regulator_match *match; + struct of_regulator_match *match; struct palmas_reg_init *rinit; struct device_node *np;
Drop static on a local variable, when the variable is initialized before any use, on every possible execution path through the function. The semantic patch that fixes this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @bad exists@ position p; identifier x; type T; @@ static T x@p; ... x = <+...x...+> @@ identifier x; expression e; type T; position p != bad.p; @@ -static T x@p; ... when != x when strict ?x = e; // </smpl> There is no reduction in code size in this case, but the change does reduce the size of the bss segment, containing uninitialized static data. before: text data bss dec hex filename 12882 3480 8 16370 3ff2 drivers/regulator/palmas-regulator.o after: text data bss dec hex filename 12882 3480 0 16362 3fea drivers/regulator/palmas-regulator.o Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> --- drivers/regulator/palmas-regulator.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html