From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:48092)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <armbru@redhat.com>) id 1bZfcI-00058p-KR
	for qemu-devel@nongnu.org; Tue, 16 Aug 2016 10:45:23 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <armbru@redhat.com>) id 1bZfcD-0001dA-Nb
	for qemu-devel@nongnu.org; Tue, 16 Aug 2016 10:45:22 -0400
Received: from mx1.redhat.com ([209.132.183.28]:53106)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <armbru@redhat.com>) id 1bZfcD-0001d0-Hx
	for qemu-devel@nongnu.org; Tue, 16 Aug 2016 10:45:17 -0400
From: Markus Armbruster <armbru@redhat.com>
References: <1470901038-9409-1-git-send-email-peterx@redhat.com>
	<1470901038-9409-2-git-send-email-peterx@redhat.com>
	<87eg5p6kk0.fsf@dusky.pond.sub.org>
	<20160816115351.GB27853@al.usersys.redhat.com>
	<20160816121708.GD9866@pxdev.xzpeter.org>
	<20160816121908.GA28518@al.usersys.redhat.com>
	<20160816140018.GG9866@pxdev.xzpeter.org>
Date: Tue, 16 Aug 2016 16:45:13 +0200
In-Reply-To: <20160816140018.GG9866@pxdev.xzpeter.org> (Peter Xu's message of
	"Tue, 16 Aug 2016 22:00:18 +0800")
Message-ID: <87zioc22o6.fsf@dusky.pond.sub.org>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [Qemu-devel] [PATCH 1/2] error-report: provide
 error_report_exit()
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: Peter Xu <peterx@redhat.com>
Cc: Fam Zheng <famz@redhat.com>, peter.maydell@linaro.org, pbonzini@redhat.com, qemu-devel@nongnu.org

Peter Xu <peterx@redhat.com> writes:

> On Tue, Aug 16, 2016 at 08:19:08PM +0800, Fam Zheng wrote:
>> On Tue, 08/16 20:17, Peter Xu wrote:
>> > > Do we really need error_report_exit when we already have error_fatal?
>> > 
>> > error_fatal is the name of a global var, not the function.
>> 
>> I mean most error_report_exit(...) calls can be converted to
>> error_setg(&error_fatal, ...).
>
> Right. But it's just another way to implement error_report_fatal(). We
> may still need error_report_fatal() since it's cleaner and shorter
> than error_setg(&error_fatal, ...).

Fam's point that

    error_report_fatal(...);

is just another way to write

    error_setg(&error_fatal, ...)

is valid.  Your point that the former is shorter and simpler is also
valid.  In fact, error.h advises:

 * Please don't error_setg(&error_fatal, ...), use error_report() and
 * exit(), because that's more obvious.
 * Likewise, don't error_setg(&error_abort, ...), use assert().

Could you convert the existing error_setg(&error_fatal, ...) to
error_report_fatal(...)?

Regarding error_report_abort(): in my opinion, printing pretty messages
right before abort() is largely a waste of time.  But if people insist
on doing it, then the error subsystem may have to support it.  Would you
be willing to track down such usage, so we can make an informed
decision?