Re: [Json] Limitations on number size?

Jacob Davies <> Wed, 05 June 2013 17:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E8FF721F9BCA for <>; Wed, 5 Jun 2013 10:52:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Jez+Ynw1p0tu for <>; Wed, 5 Jun 2013 10:52:28 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c00::233]) by (Postfix) with ESMTP id 4452D21F9B32 for <>; Wed, 5 Jun 2013 10:52:21 -0700 (PDT)
Received: by with SMTP id i13so1332758qae.3 for <>; Wed, 05 Jun 2013 10:52:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=eY2wIq4NupbP/A1b9PK+KNieC85nVuWqUEId3YuqM68=; b=Y5d+909qBXEaY1HKn14p01fXMH158Cq1hRjHsPu5ni7byQj4OTRI947Hvp9Hk+SLql Bxx49MV/yJvLSiAw1Shlf7PwzKRtmNg7vyoxaF4PVczQ51it0kFmGQKApmQlop3leO9C VjqyHiXl4QPs24EtUlVRM6Y90xdE3tHq8ZVVh2rOHbWr4r8yCTkltwl9E/MUwmcebsDh 53fT8OelascF2GnjnaHO0Ez4I9I7zs+L4THFKHHHZ3kedJPbh2g+RkXzaZ0m9tGYqus+ wqU76TZMZL5GzWIxeH9PnxLUP5DzLWp3yI6BPPIHl7BEGlM1b/1iJSPD9ImYjNwKLCy0 Eehg==
X-Received: by with SMTP id fk4mr49162qcb.88.1370454738926; Wed, 05 Jun 2013 10:52:18 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 5 Jun 2013 10:51:58 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Jacob Davies <>
Date: Wed, 5 Jun 2013 10:51:58 -0700
X-Google-Sender-Auth: gM6bqGPy3HXdhPrFKl1IsQOoygw
Message-ID: <>
To: "" <>
Content-Type: multipart/alternative; boundary=001a11c29274e5358204de6bdbbd
Subject: Re: [Json] Limitations on number size?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Jun 2013 18:06:39 -0000

On Tue, Jun 4, 2013 at 9:05 PM, Nico Williams <> wrote:

> It might be nice to be able to specify some ranges that MUST be
>  supported by decoders, but in practice I think we can't (and probably
> shouldn't try to) even do that.

My past reading of the number section and the many references to Javascript
in the spec led me to believe that the number type was Javascript's number
type, and that compliance required you to accept & emit numbers only in
that range (i.e. IEEE 754 64-bit numbers minus NaN and infinities).

Implementation limits on the length of strings or size of arrays or objects
were not specified either, but those are large enough in most languages
that you're unlikely to run into them unexpectedly; if you are thinking of
sending a terabyte of text in string or an object with a trillion keys it
has probably occurred to you that some special interoperability concerns
will apply. But just sending large 64-bit integers as numbers in a JSON
string will cause you interoperability problems with Javascript and a lot
of other JSON parsers, and my experience & some quick searches indicate
this has been a common bug (or misunderstanding, perhaps) in

I wouldn't say a size restriction should be specified either. But I think
it might be worth noting this particular interoperability concern in the
specification rather than just as a best practice.