From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:59428)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1ScKd0-0005Sa-1D
	for qemu-devel@nongnu.org; Wed, 06 Jun 2012 14:06:43 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1ScKcw-0008SU-Gn
	for qemu-devel@nongnu.org; Wed, 06 Jun 2012 14:06:41 -0400
Received: from mx1.redhat.com ([209.132.183.28]:18057)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1ScKcw-0008SD-8p
	for qemu-devel@nongnu.org; Wed, 06 Jun 2012 14:06:38 -0400
Message-ID: <4FCF8DF6.8050502@redhat.com>
Date: Wed, 06 Jun 2012 19:05:58 +0200
From: Laszlo Ersek <lersek@redhat.com>
MIME-Version: 1.0
References: <1337683555-13301-1-git-send-email-lersek@redhat.com>
	<4FCE7684.2070206@redhat.com> <4FCF5512.9000704@redhat.com>
	<4FCF5BA8.3010201@suse.de> <4FCF64E4.50701@redhat.com>
	<20120606151640.GA7733@illuin> <4FCF777B.7000806@redhat.com>
	<20120606161446.GC7733@illuin> <4FCF8A0F.3020306@redhat.com>
In-Reply-To: <4FCF8A0F.3020306@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 00/16] introduce OptsVisitor,
 rebase -net/-netdev parsing
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: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, =?ISO-8859-1?Q?Andreas_F=E4rbe?= =?ISO-8859-1?Q?r?= <afaerber@suse.de>, qemu-devel@nongnu.org

On 06/06/12 18:49, Laszlo Ersek wrote:

> The fallback (*v->type_int)() call stores an int64_t, according to its
> prototype ("interface contract"). IMHO it shouldn't try to communicate a
> mathematical value outside of [INT64_MIN, INT64_MAX]; it should report
> an error in this case.

Suppose the v->type_int() call fails and stores a parse error (and that
correspondingly it doesn't modify "value").

Suppose the subsequent range check fails too. In this case the current
code leaks the first Error object.

I didn't try to fix this here because my series starts with a patch from
Paolo that fixes this leak: once an error is pending, further errors are
thrown away (= not formatted / released). With that fix in place, it
doesn't matter if we enter the (value < 0) branch or not: as long as
type_int keeps error setting and value changing mutually exclusive,
we'll keep the first (= type_int) error and keep the value of *obj too.

Laszlo