- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 17 Nov 2016 10:01:10 +0100
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Kazuho Oku <kazuhooku@gmail.com>, Poul-Henning Kamp <phk@critter.freebsd.dk>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Nov 17, 2016 at 09:01:35AM +0100, Julian Reschke wrote: > > For example, if we want to define a quality value like the one found > > in Accept-Encoding, we should not use three-digit fixed point numbers, > > but instead use an integral value between 0 to 1000. > > > > That way, we can totally avoid the issues introduced by a dot within a number. > > ... > > +1 in general, but that approach wouldn't work well in cases where we want > to allow different levels of precision (such as timestamps that optionally > would allow fractions of seconds) Sure but that's one example where we know the 53-bit mantissa already fails to represent sub-microsecond when the seconds represent the unix time since the epoch, so a struct timespec is misrepresented there. On the other hand most of the time we don't care about the sub-microsecond accuracy, it just has to be known (hence documented) that writing timestamp 1479372852.095647253 to represent what I'm seeing now may very well end up being read as 1479372852.095648125 for example. Another option could be to state that some numbers can include a fractional part and that this part has to be processed separately *if required*. That's already OK for q= after all, which for many cases doesn't require accurate processing : q=0 => always 0 q=0.something => always >0 and <1 q=1 => always 1 Or maybe Poul-Henning's 15-digit number can solve it as well. But we must not use it for any number as it would remove the ability to pass 64-bit integers. Regards, Willy
Received on Thursday, 17 November 2016 09:01:51 UTC