- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Wed, 12 Dec 2018 07:45:45 +0000
- To: Mark Nottingham <mnot@mnot.net>
- cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
-------- In message <E41E7F06-2A34-45BE-820C-507C78102CDB@mnot.net>, 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 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Wednesday, 12 December 2018 07:46:10 UTC