This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/16437] New: struct timespec definition is non-conforming on x32 and perhaps other archs
- From: "bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Sat, 11 Jan 2014 17:50:54 +0000
- Subject: [Bug libc/16437] New: struct timespec definition is non-conforming on x32 and perhaps other archs
- Auto-submitted: auto-generated
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.