From owner-freebsd-arch@FreeBSD.ORG  Fri Jul 26 21:14:03 2013
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: arch@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTP id 7039BB0;
 Fri, 26 Jul 2013 21:14:03 +0000 (UTC)
 (envelope-from brde@optusnet.com.au)
Received: from mail110.syd.optusnet.com.au (mail110.syd.optusnet.com.au
 [211.29.132.97])
 by mx1.freebsd.org (Postfix) with ESMTP id 2FAAE207B;
 Fri, 26 Jul 2013 21:14:02 +0000 (UTC)
Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au
 (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23])
 by mail110.syd.optusnet.com.au (Postfix) with ESMTPS id EE2797806EF;
 Sat, 27 Jul 2013 07:13:52 +1000 (EST)
Date: Sat, 27 Jul 2013 07:13:51 +1000 (EST)
From: Bruce Evans <brde@optusnet.com.au>
X-X-Sender: bde@besplex.bde.org
To: Pawel Jakub Dawidek <pjd@freebsd.org>
Subject: Re: General purpose library for name/value pairs.
In-Reply-To: <20130726181108.GA1811@garage.freebsd.pl>
Message-ID: <20130727070531.D4895@besplex.bde.org>
References: <20130704215329.GG1402@garage.freebsd.pl>
 <4818.1373008073@critter.freebsd.dk>
 <20130705195255.GB25842@garage.freebsd.pl>
 <60317.1373055040@critter.freebsd.dk>
 <20130708150308.GE1383@garage.freebsd.pl>
 <717D098F-D07E-45B0-B9F0-8D8BCEF06923@mail.turbofuzz.com>
 <20130708213351.GB1405@garage.freebsd.pl>
 <D2E98A8F-F765-4A56-96CD-4410944A2910@turbofuzz.com>
 <20130725202832.GD1400@garage.freebsd.pl>
 <20130726175858.Y1061@besplex.bde.org>
 <20130726181108.GA1811@garage.freebsd.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Optus-CM-Score: 0
X-Optus-CM-Analysis: v=2.1 cv=Yos2GeoX c=1 sm=1 tr=0
 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=kxgCfahG5_wA:10
 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=_Sy8tSWxdDoA:10
 a=ctWZexKtWnL2h3DUuaYA:9 a=CjuIK1q_8ugA:10
Cc: arch@freebsd.org, "Jordan K. Hubbard" <jordan.hubbard@gmail.com>
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jul 2013 21:14:03 -0000

On Fri, 26 Jul 2013, Pawel Jakub Dawidek wrote:

> On Fri, Jul 26, 2013 at 06:04:15PM +1000, Bruce Evans wrote:
>> On Thu, 25 Jul 2013, Pawel Jakub Dawidek wrote:
>>
>>> Returning to this thread after a short break. I removed all
>>> {,u}int{8,16.32.64} types and implemented only 'number' type which is
>>> uint64_t. Looks much nicer now.
>>
>> The numeric type should be floating point.  Or better yet, bignum.  Or
>> more practically, uintmax_t.
>
> The uintmax_t in theory can change in the future, which would make
> sending numeric type from system with larger uintmax_t to system with
> smaller uintmax_t problematic.

Using uint64_t is especially broken then, since uint64_t is too small to
represent numbers on the system with larger uintmax_t.  But how is the
data sent across systems by your API?

Bruce