[Bug libc/16437] New: struct timespec definition is non-conforming on x32 and perhaps other archs

["bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=16437

            Bug ID: 16437
           Summary: struct timespec definition is non-conforming on x32
                    and perhaps other archs
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: bugdal at aerifal dot cx
                CC: drepper.fsp at gmail dot com

glibc's definition of struct timespec is wrong: it's using __syscall_slong_t
rather than long. This violates the requirements of both POSIX and C11. See C11
7.27.1 Components of time, paragraph 4:

"The range and precision of times representable in clock_t and time_t are
implementation-defined. The timespec structure shall contain at least the
following members, in any order.

         time_t tv_sec; // whole seconds -- >= 0
         long   tv_nsec; // nanoseconds -- [0, 999999999]"

This breaks conforming code such as:

struct timespec ts;
sscanf("42", "%ld", &ts.tv_nsec);

on targets where __syscall_slong_t is not simply long. For example, on x32,
after the above sscanf call, the upper bits of ts.tv_nsec will still contain
junk. This is just one example of the breakage; there are many others.

Unfortunately fixing this is difficult because the kernel is broken too; simply
correcting the type will result in userspace failing to zero the upper bits,
which the kernel will then wrongly read as part of a 64-bit value.
kernel/compat.c should be zeroing the upper bits of tv_nsec when reading
timespec from userspace. Unless it does so, workaround code is required in
userspace to copy timespec to a temp buffer before passing it to the kernel and
to sign-extend the temporary copy into the padding bits which the kernel will
wrongly interpret as value bits.

I'm not sure if other archs (maybe MIPS n32?) are also affected.

-- 
You are receiving this mail because:
You are on the CC list for the bug.