Date: Sat, 27 Jul 2013 07:13:51 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Pawel Jakub Dawidek <pjd@freebsd.org> Cc: arch@freebsd.org, "Jordan K. Hubbard" <jordan.hubbard@gmail.com> Subject: Re: General purpose library for name/value pairs. Message-ID: <20130727070531.D4895@besplex.bde.org> In-Reply-To: <20130726181108.GA1811@garage.freebsd.pl> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130727070531.D4895>