Subject: SH: Integer limits

From: Mark Nottingham <[email-masked]>
Date: Wed, 12 Dec 2018 11:00:11 +0900

I've just opened <https://github.com/httpwg/http-extensions/issues/737>. 

"""
Working on evert/structured-headers, @evert noticed that representing the full range of SH integers is hard, and going beyond it can cause problems.

Given JS's place in the Web ecosystem and the relative rarity of headers that need integers that big (as well as the availability of floats), should we consider limiting the range of integer to match JS?
"""

Relevant link: http://2ality.com/2013/10/safe-integers.html

Thoughts?

--
Mark Nottingham   https://www.mnot.net/

---

From: Martin Thomson <[email-masked]>
Date: Wed, 12 Dec 2018 16:16:52 +1100

Are you thinking 2^53-1 (the largest integer that can be faithfully
represented in JS) or 2^32-1 (the largest integer that can be treated
as an integer in JS)?

I see from the reference you are probably thinking the former.  The
latter might be safer if you can justify it though. Are there cases
where the larger range might be needed?

I have a feeling that the answer is "yes", because 4Gb isn't that big
a value and we have range header fields.  Is that what you are
thinking?

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 12 Dec 2018 15:50:14 +0900

> On 12 Dec 2018, at 2:16 pm, Martin Thomson <[email-masked]> wrote:
> 

I was thinking of the former. For the latter, are you referring to this:

"""
Some ECMAScript operators deal only with integers in the range −2^31 through 2^31−1, inclusive, or in the range 0 through ^232−1, inclusive. These operators accept any value of the Number type but first convert each such value to one of 2^32 integer values. See the descriptions of the ToInt32 and ToUint32 operators in 9.5 and 9.6, respectively.
"""
 -- https://www.ecma-international.org/ecma-262/5.1/#sec-8.5

?

From looking at the rest of the spec briefly, it looks like we lose some bitwise and shift operators as a result -- is that correct? 

If so, my take would be that the higher limit is probably worth it; if a header needs to use bitwise/shift operators on large headers, that seems like something that could be dealt with in a few ways.

> a value and we have range header fields.  Is that what you are

Not specifically.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 12 Dec 2018 17:58:27 +1100

> From looking at the rest of the spec briefly, it looks like we lose some bitwise and shift operators as a result -- is that correct?

Yeah, and some of those can be synthesized.  <<1 can become *2.  The
loss doesn't seem particularly bad. The gain (2^22 times more space)
seems like a serious upside.

That this popular language is driving this decision is the only thing
that bothers me.  Yes, it's a popular language, but it's probably the
only one that doesn't have native 64-bit numbers (yet --
https://tc39.github.io/proposal-bigint/).

Would the use of bignums change this calculus?

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 12 Dec 2018 07:45:45 +0000

--------
In message <[email-masked]>, Mark Nottingham wri
tes:

>"""
>Working on evert/structured-headers, @evert noticed that representing 
>the full range of SH integers is hard, and going beyond it can cause 
>problems.
>
>Given JS's place in the Web ecosystem and the relative rarity of headers 
>that need integers that big (as well as the availability of floats), 
>should we consider limiting the range of integer to match JS?
>"""

>Thoughts?

Way back I limited Floats, or "Numbers" as I think I called them,
to 15 digits so they would fit in ieee64 floting point types, this
became our "Float" type, which still has that restriction.

Integers were added, I thought, precisely to give the full
64 bit integer range without that limitation ?

If we want to go back and cater to JS implementations, we should
remove Integers again, rename Float back to Number, add the
"15DIGIT" variant back and leave it to people to specify "Number
without fraction" in their usage of SH.

It's early in the morning and I fought a server all night, so subject
to me waking up I think my preference probably is to make it a
mandatory parsing error if an Integer cannot be represented precisly
in the target environment, with a pointed caution/footnote about JS ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 12 Dec 2018 08:48:27 +0100

On 2018-12-12 07:58, Martin Thomson wrote:
> ...

In particular as this was one of the reasons to drop the JSON-based 
approach in the first place...

Best regards, Julian