From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:37099)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <armbru@redhat.com>) id 1bCjTw-000572-Fy
	for qemu-devel@nongnu.org; Tue, 14 Jun 2016 04:13:57 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <armbru@redhat.com>) id 1bCjTv-000089-HP
	for qemu-devel@nongnu.org; Tue, 14 Jun 2016 04:13:56 -0400
From: Markus Armbruster <armbru@redhat.com>
References: <1465589538-24998-1-git-send-email-ehabkost@redhat.com>
	<1465589538-24998-4-git-send-email-ehabkost@redhat.com>
	<87r3c1wclw.fsf@dusky.pond.sub.org>
	<20160613214000.GM18662@thinpad.lan.raisama.net>
Date: Tue, 14 Jun 2016 10:13:50 +0200
In-Reply-To: <20160613214000.GM18662@thinpad.lan.raisama.net> (Eduardo
	Habkost's message of "Mon, 13 Jun 2016 18:40:00 -0300")
Message-ID: <8760tcmblt.fsf@dusky.pond.sub.org>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [Qemu-devel] [RFC v2 3/3] Remove unnecessary variables for
 function return value
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: kwolf@redhat.com, qemu-block@nongnu.org, qemu-devel@nongnu.org, mreitz@redhat.com, borntraeger@de.ibm.com, cornelia.huck@de.ibm.com

Eduardo Habkost <ehabkost@redhat.com> writes:

> On Mon, Jun 13, 2016 at 01:29:47PM +0200, Markus Armbruster wrote:
>> Eduardo Habkost <ehabkost@redhat.com> writes:
>> 
>> > Use Coccinelle script to replace 'ret = E; return ret' with
>> > 'return E'. The script will do the substitution only when the
>> > function return type and variable type are the same.
>> >
>> > Sending as RFC because the patch looks more intrusive than the
>> > others. Probably better to split it per subsystem and let each
>> > maintainer review and apply it?
>> 
>> As far as I'm concerned, obvious mechanical cleanups like this one can
>> go in as a single tree-wide patch.  I'd consider making you split it up,
>> then chase maintainers a waste of your time[*].
>
> Not wasting my time sounds like a good idea. :)
>
> Once the issues below are fixed and Eric's comments are
> addressed, should it go through your error reporting tree?

Yes.