Re: [Json] Limitations on number size?

Nico Williams <nico@cryptonector.com> Tue, 09 July 2013 22:31 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2796611E8181 for <json@ietfa.amsl.com>; Tue, 9 Jul 2013 15:31:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.421
X-Spam-Level:
X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iq7ZxxkUYMu for <json@ietfa.amsl.com>; Tue, 9 Jul 2013 15:31:11 -0700 (PDT)
Received: from homiemail-a96.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 6380911E817A for <json@ietf.org>; Tue, 9 Jul 2013 15:31:11 -0700 (PDT)
Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 6BC643B806C for <json@ietf.org>; Tue, 9 Jul 2013 15:31:04 -0700 (PDT)
Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id 11FB53B8059 for <json@ietf.org>; Tue, 9 Jul 2013 15:31:03 -0700 (PDT)
Received: by mail-wi0-f171.google.com with SMTP id hj3so10736615wib.16 for <json@ietf.org>; Tue, 09 Jul 2013 15:31:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N4tqH95q3bLG2VWiGHcjgZRp4BkOgfmX7vFSlQRexio=; b=mro6RqofP+z8r9ZFXfoW6WJVOSuq9II9I42cNCmFqVINFEdnDDXq5jBPwDGgIAgHHX gn6g2hDaSPFN8RUSPQ0Nb0sbozY2pQ/PsZtRP5HsXfWQBktHzRC2vtvZm8AZPAow3866 /bednnwU6NJgzdikut1pj4IelDyfXyjr4sRa6ZXegt/1b7uA2dWCrkgcPTa+bMG9UHZA sHRsnh/7vkoD9ddMUBF8ugUcL/kg2YeQPyds0aEnyeWd5m/aCl+xrVUb4Xugp8ruwkN5 mRnC1+ZSxC+igYcl3sFHqksrZJJMXWySaU5QnA5aG0nsm8sLIoSFN2oXKZjQPB8DNO5Y sR1A==
MIME-Version: 1.0
X-Received: by 10.194.48.116 with SMTP id k20mr16597377wjn.23.1373409062548; Tue, 09 Jul 2013 15:31:02 -0700 (PDT)
Received: by 10.217.38.138 with HTTP; Tue, 9 Jul 2013 15:31:02 -0700 (PDT)
In-Reply-To: <20130709222601.32831.qmail@joyce.lan>
References: <CAK3OfOi_q8KTQd-RW7PPhS5ZXXYSMEJ57uKTKL-ck6ocd6Nbeg@mail.gmail.com> <20130709222601.32831.qmail@joyce.lan>
Date: Tue, 9 Jul 2013 17:31:02 -0500
Message-ID: <CAK3OfOiefw=58P-K8WCKQJc=JodC1CWtq=mSE5_gpC8fw6_-Vg@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: John Levine <johnl@taugh.com>
Content-Type: text/plain; charset=UTF-8
Cc: json@ietf.org
Subject: Re: [Json] Limitations on number size?
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jul 2013 22:31:17 -0000

On Tue, Jul 9, 2013 at 5:26 PM, John Levine <johnl@taugh.com> wrote:
>>1) give advice as to what numeric ranges and precisions are generally
>>supported (e.g., 32-bit signed integers);
>
> Do we actually know?  Or is it just whatever number format a library's
> underlying language happens to provide?

I've contributed to one JSON implementation that doesn't do better
than 32-bit signed integers.  I've contributed to one that uses C
doubles.

I doubt there's any that support only 0-bit numbers (heh).  And I
doubt there are any that only support 16-bit integers (or that we'd
care about them, but who knows).

I *suspect* 32-bit signed, or perhaps 31-bit unsigned integers is the
minimum that all implementations we'd care about support.

We might want to do a survey.