From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757790AbcHWLEw (ORCPT ); Tue, 23 Aug 2016 07:04:52 -0400 Received: from canardo.mork.no ([148.122.252.1]:58236 "EHLO canardo.mork.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752554AbcHWLEu (ORCPT ); Tue, 23 Aug 2016 07:04:50 -0400 From: =?utf-8?Q?Bj=C3=B8rn_Mork?= To: "Michael S. Tsirkin" Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Jonathan Corbet , virtualization@lists.linux-foundation.org, Julia Lawall , Dan Carpenter Subject: Re: [PATCH] CodingStyle: add some more error handling guidelines Organization: m References: <1471874251-7721-1-git-send-email-mst@redhat.com> Date: Tue, 23 Aug 2016 13:03:15 +0200 In-Reply-To: <1471874251-7721-1-git-send-email-mst@redhat.com> (Michael S. Tsirkin's message of "Mon, 22 Aug 2016 16:57:46 +0300") Message-ID: <87mvk3vjbg.fsf@miraculix.mork.no> User-Agent: Gnus/5.130015 (Ma Gnus v0.15) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 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-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id u7NB4uJ5022301 "Michael S. Tsirkin" writes: > foo = kmalloc(SIZE, GFP_KERNEL); > if (!foo) > goto err_foo; > > foo->bar = kmalloc(SIZE, GFP_KERNEL); > if (!foo->bar) > goto err_bar; > ... > > kfree(foo->bar); > err_bar: > > kfree(foo); > err_foo: > > return ret; I believe the CodingStyle already contain far too much personal style to be useful as real style guide. FWIW, I prefer a single error label, at the "cost" of additional tests in the error path: foo = kmalloc(SIZE, GFP_KERNEL); if (!foo) goto err; foo->bar = kmalloc(SIZE, GFP_KERNEL); if (!foo->bar) goto err; ... if (ret) goto err; return 0; err: if (foo) kfree(foo->bar); kfree(foo); return ret; The advantage is that I don't have to manage X different labels, ensuring that they have the order is correct if some part of the function is refactored etc. That tends to get too complicated for my simple brain. And since the error path is rarely tested, complicated equals buggy. My sample will of course trigger all those nice "optimizing the error path" patches, but I ignore those anyway so that's not a big deal. Bjørn