From 3876833ad82ad16c92647e556e50a893a52f6c0e Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 22 Jun 2024 20:42:04 -0400 Subject: [PATCH] Fix FIXME in comment * src/timefns.c (decode_float_time): Explain why the code can use large precision here, removing a FIXME by updating the containing comment. (cherry picked from commit 2b848a4e504319cce150000a2c3855f66d89714b) --- src/timefns.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/src/timefns.c b/src/timefns.c index 0ecbb6e6793..746e422ffb6 100644 --- a/src/timefns.c +++ b/src/timefns.c @@ -414,9 +414,11 @@ decode_float_time (double t, struct lisp_time *result) else { int scale = double_integer_scale (t); - /* FIXME: `double_integer_scale` often returns values that are - "pessimistic" (i.e. larger than necessary), so 3.5 gets converted - to (7881299347898368 . 2251799813685248) rather than (7 . 2). + /* Because SCALE treats trailing zeros in T as significant, + on typical platforms with IEEE floating point + (time-convert 3.5 t) yields (7881299347898368 . 2251799813685248), + a precision of 2**-51 s, not (7 . 2), a precision of 0.5 s. + Although numerically correct, this generates largish integers. On 64bit systems, this should not matter very much, tho. */ eassume (scale < flt_radix_power_size); -- 2.39.2