From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:60325)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1ScLVb-000571-23
	for qemu-devel@nongnu.org; Wed, 06 Jun 2012 15:03:12 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1ScLVR-000404-4c
	for qemu-devel@nongnu.org; Wed, 06 Jun 2012 15:03:06 -0400
Received: from mx1.redhat.com ([209.132.183.28]:13082)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1ScLVQ-0003zZ-TE
	for qemu-devel@nongnu.org; Wed, 06 Jun 2012 15:02:57 -0400
Message-ID: <4FCF8A0F.3020306@redhat.com>
Date: Wed, 06 Jun 2012 18:49:19 +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>
In-Reply-To: <20120606161446.GC7733@illuin>
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:14, Michael Roth wrote:
> On Wed, Jun 06, 2012 at 05:30:03PM +0200, Laszlo Ersek wrote:

>>   value < 0
> 
> I think this last one will cause problems though, since uint64_t's
> within the valid range for visit_type_uint64() will fail due to being
> interpreted as < 0 when cast to int64_t. With the others we can detect
> these cases since the max unsigned value doesn't exceed the max signed
> value of the intermediate type we're storing to.

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. If a visitor genuinely wants to parse and store
2^63 for example, it should implement the "type_uint64" interface.

Anyway I've been called "inflexible" before. I can send a v2 if you wish.

Thanks,
Laszlo