[glib: 1/2] g_file_info_get_modification_date_time: Calculate in integer domain



commit 14609b0b256b9c13162719868d4dfc2b419d885f
Author: Simon McVittie <smcv collabora com>
Date:   Tue Oct 1 23:27:53 2019 +0100

    g_file_info_get_modification_date_time: Calculate in integer domain
    
    g_date_time_add_seconds() and g_date_time_add_full() use floating-point
    seconds, which can result in the value varying slightly from what's
    actually on disk. This causes intermittent test failures in
    gio/tests/g-file-info.c on Debian i386, where we set a file's mtime
    to be 50µs later, then read it back and sometimes find that it is only
    49µs later than the previous value.
    
    I've only seen this happen on i386, which means it might be to do with
    different floating-point rounding when a value is stored in the 80-bit
    legacy floating point registers rather than in double precision.
    
    g_date_time_add() takes a GTimeSpan, which is in microseconds;
    conveniently, that's exactly what we get from the GFileInfo.
    
    Bug-Debian: https://bugs.debian.org/941547
    Signed-off-by: Simon McVittie <smcv collabora com>

 gio/gfileinfo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
---
diff --git a/gio/gfileinfo.c b/gio/gfileinfo.c
index 0f3026c3f..3d7561b11 100644
--- a/gio/gfileinfo.c
+++ b/gio/gfileinfo.c
@@ -1822,7 +1822,7 @@ g_file_info_get_modification_date_time (GFileInfo *info)
   if (value_usec == NULL)
     return g_steal_pointer (&dt);
 
-  dt2 = g_date_time_add_seconds (dt, _g_file_attribute_value_get_uint32 (value_usec) / (gdouble) 
G_USEC_PER_SEC);
+  dt2 = g_date_time_add (dt, _g_file_attribute_value_get_uint32 (value_usec));
   g_date_time_unref (dt);
 
   return g_steal_pointer (&dt2);


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]