Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751773AbdINViW (ORCPT ); Thu, 14 Sep 2017 17:38:22 -0400 Received: from mail-io0-f195.google.com ([209.85.223.195]:37496 "EHLO mail-io0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751335AbdINViV (ORCPT ); Thu, 14 Sep 2017 17:38:21 -0400 X-Google-Smtp-Source: AOwi7QC3V6jOUHmi7oV/gVTpZWqm/IIOB/t2GfXKZJzGHWf23YMw5pNazSxAkgkX/pvbDF6Zju7drKA5otedjv37Tzs= MIME-Version: 1.0 In-Reply-To: References: <20170914110709.3591691-1-arnd@arndb.de> From: Arnd Bergmann Date: Thu, 14 Sep 2017 23:38:19 +0200 X-Google-Sender-Auth: N7HPl5_rI6RZereL_U-UrDdoFfw Message-ID: Subject: Re: [PATCH] mtd: spi-nor: stm32-quadspi: avoid unintialized return code To: Ludovic BARRE 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1399 Lines: 44 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. Arnd