Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751400AbdIOIAW (ORCPT ); Fri, 15 Sep 2017 04:00:22 -0400 Received: from mx07-00178001.pphosted.com ([62.209.51.94]:40934 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750865AbdIOIAU (ORCPT ); Fri, 15 Sep 2017 04:00:20 -0400 Subject: Re: [PATCH] mtd: spi-nor: stm32-quadspi: avoid unintialized return code To: Arnd Bergmann CC: Geert Uytterhoeven , Cyrille Pitchen , Marek Vasut , Boris Brezillon , Alexandre Torgue , Richard Weinberger , "linux-kernel@vger.kernel.org" , MTD Maling List , "linux-arm-kernel@lists.infradead.org" , Maxime Coquelin , Brian Norris , David Woodhouse References: <20170914110709.3591691-1-arnd@arndb.de> From: Ludovic BARRE Message-ID: Date: Fri, 15 Sep 2017 09:59:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.75.127.47] X-ClientProxiedBy: SFHDAG3NODE3.st.com (10.75.127.9) To SFHDAG6NODE1.st.com (10.75.127.16) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-09-15_02:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1623 Lines: 55 On 09/14/2017 11:38 PM, Arnd Bergmann wrote: > On Thu, Sep 14, 2017 at 6:55 PM, Ludovic BARRE wrote: >> >> >> On 09/14/2017 05:24 PM, Geert Uytterhoeven wrote: >>> >>> Hi Ludovic, >>> >>> On Thu, Sep 14, 2017 at 5:13 PM, Ludovic BARRE >>> wrote: >>>> >>>> On 09/14/2017 03:38 PM, Geert Uytterhoeven wrote: >>>> >>>> hi Arnd, Geert >>>> >>>> sorry, I was forgot this thread while my holidays >>>> >>>> Geert: what do you mean like "similar bugs in the future" in "If you >>>> initialized ret at the beginning, you lose the ability to catch newly >>>> introduced similar bugs in the future." >>> >>> >>> If you pre-initialize ret at the top, you loose the ability of the >>> compiler >>> to detect at compile-time if ret is never written to later. It will just >>> return >>> -EINVAL at runtime. >>> >>> With my version, if the code is modified later and another "return ret" is >>> added, the compiler will detect if there's a code path that forgets >>> to assign a value to ret. >> >> Ok, it's clear for me. >> I favor geert's solution. >> Arnd what do you think ? > > I usually follow the same rule that Geert explained (and quote > https://rusty.ozlabs.org/?p=232 when I do so). In this case, there > did not seem to be much value as the variable is not used > afterwards, and I kept the 'single return statement' guideline. > > In the end, either version seems totally fine to me here, so > please use Geert's if you prefer that. thank Arnd for your answer, great link :-) we take geert's patch. Geert: I will acked your patch. thanks everybody > > Arnd >