From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S933081AbdHVPH5 (ORCPT <rfc822;w@1wt.eu>);
        Tue, 22 Aug 2017 11:07:57 -0400
Received: from mx2.suse.de ([195.135.220.15]:48720 "EHLO mx1.suse.de"
        rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP
        id S932329AbdHVPH4 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 22 Aug 2017 11:07:56 -0400
Date: Tue, 22 Aug 2017 17:07:54 +0200
Message-ID: <s5hwp5v7i9h.wl-tiwai@suse.de>
From: Takashi Iwai <tiwai@suse.de>
To: SF Markus Elfring <elfring@users.sourceforge.net>
Cc: alsa-devel@alsa-project.org, kernel-janitors@vger.kernel.org,
        LKML <linux-kernel@vger.kernel.org>,
        Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [alsa-devel] ALSA: pcsp: Use common error handling code in snd_card_pcsp_probe()
In-Reply-To: <b434f976-33a1-7ced-55b5-b55487f2fb14@users.sourceforge.net>
References: <08ee0d6b-788b-2845-6964-e1e55c2d2292@users.sourceforge.net>
        <20170822121625.syvr64kwyh5xjexg@mwanda>
        <s5hziar9483.wl-tiwai@suse.de>
        <f138ba40-a61f-cdab-3d9b-699dbcacad9d@users.sourceforge.net>
        <s5ho9r792yl.wl-tiwai@suse.de>
        <fc4d8c96-7de2-e8f0-4cb4-5dda795d298a@users.sourceforge.net>
        <s5hbmn78zmg.wl-tiwai@suse.de>
        <139363f6-e059-defb-357e-f18645ba9768@users.sourceforge.net>
        <s5h378j8xos.wl-tiwai@suse.de>
        <b434f976-33a1-7ced-55b5-b55487f2fb14@users.sourceforge.net>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka)
 FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.2
 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, 22 Aug 2017 17:03:00 +0200,
SF Markus Elfring wrote:
> 
> >> * I find it a bit safer when the error predicate is “return value != 0”.
> > 
> > Can't agree.
> 
> How do you think about to reduce the probability that positive return values
> will accidentally be interpreted as a successful function execution.

It's not zero.

> > And I have no interest to continue bike-shedding, sorry.
> 
> I do not like that you prefer to put this technical detail into such
> a communication category.
> 
> 
> > You can't convince me regarding this.
> 
> Would you still like to integrate the proposed refactoring with the use
> of previous failure predicates then?

That's fine.

But, please don't forget what others already mentioned.
For example, Joe Perches suggested to put a blank line before the
label for your patches.  But you completely ignored it and did the
same again.


thanks,

Takashi