From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.web.de (mout.web.de [212.227.15.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3yGmPz0X7FzDqlv for ; Wed, 18 Oct 2017 07:05:10 +1100 (AEDT) Subject: Re: char/tpm: Improve a size determination in nine functions To: Mimi Zohar , linux-integrity@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Cc: Julia Lawall , Alexander Steffen , linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org, Andy Shevchenko , Benjamin Herrenschmidt , Corentin Labbe , Jarkko Sakkinen , Jason Gunthorpe , Jerry Snitselaar , Kenneth Goldman , Michael Ellerman , Nayna Jain , Paul Mackerras , =?UTF-8?Q?Peter_H=c3=bcwe?= , Stefan Berger References: <1d3516a2-a8e6-9e95-d438-f115fac84c7f@users.sourceforge.net> <83a166af-aecc-649d-dfe3-a72245345209@users.sourceforge.net> <1508238182.16112.475.camel@linux.intel.com> <1508244757.4234.60.camel@linux.vnet.ibm.com> <1508253453.4234.81.camel@linux.vnet.ibm.com> <9689f036-ba9f-d23b-cf89-c289bc308771@users.sourceforge.net> <1508268493.4513.39.camel@linux.vnet.ibm.com> From: SF Markus Elfring Message-ID: <0c0adf54-ecaa-0a46-d4d0-1cd9718de913@users.sourceforge.net> Date: Tue, 17 Oct 2017 22:04:30 +0200 MIME-Version: 1.0 In-Reply-To: <1508268493.4513.39.camel@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8 List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , >> Do you find my wording “This issue was detected by using the >> Coccinelle software.” insufficient? > > The question is not whether it is insufficient, but whether it is appropriate. I am curious on how our corresponding discussion will evolve further. > Detecting Coccinelle issues is one step.  The next step is deciding > what to do with them. Will the clarification achieve any more useful results? > Up to now, these messages have been sent out as informational, not as patches. I sent some update suggestions as patches also in this series (as usual). > Before sending patches to change existing code, address the "problem" > so that it doesn't continue to happen. It might be very challenging to achieve such a goal. > Only afterwards is it appropriate to discuss what to do with existing code. I would prefer to get corresponding improvements in both areas in parallel (if it is generally possible). Regards, Markus