This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [ping2][PATCH v2][BZ #12515] Improve precision of clock function
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 10 Jun 2013 16:45:38 -0700
- Subject: Re: [ping2][PATCH v2][BZ #12515] Improve precision of clock function
- References: <20130521145611 dot GM8927 at spoyarek dot pnq dot redhat dot com> <20130521151839 dot GA18430 at domone dot kolej dot mff dot cuni dot cz> <20130521153442 dot GO8927 at spoyarek dot pnq dot redhat dot com> <519B9A09 dot 6030305 at cs dot ucla dot edu> <20130521161441 dot GQ8927 at spoyarek dot pnq dot redhat dot com> <20130603092604 dot GL2145 at spoyarek dot pnq dot redhat dot com> <20130610083821 dot GD1570 at spoyarek dot pnq dot redhat dot com>
On 06/10/13 01:38, Siddhesh Poyarekar wrote:
>>> + if (__clock_gettime (CLOCK_PROCESS_CPUTIME_ID, &ts) == 0)
>>> + return (ts.tv_sec * CLOCKS_PER_SEC
>>> + + ts.tv_nsec / (1000000000 / CLOCKS_PER_SEC));
Sorry, now that I'm thinking about it, I thought of two more
things.
First, the above code relies on wraparound arithmetic after
signed integer overflow, assuming time_t is signed, but GCC
doesn't guarantee this by default. So, should
the function containing the above code be preceded by a pragma,
like this?
#pragma GCC optimize ("wrapv")
I ask this because I don't know what glibc's assumptions are
about integer overflow -- when there's a signed integer overflow
does glibc assume -fwrapv behavior or undefined behavior?
(The same question applies to the old version of clock.c, of
course, but while we're in the neighborhood....)
Second, 'clock' is weird since POSIX specifically
mentions wraparound as an allowed behavior, whereas C11
says that wraparound is not allowed. POSIX will be changed
to match C11; see:
http://austingroupbugs.net/bug_view_page.php?bug_id=686
and also see:
http://austingroupbugs.net/bug_view_page.php?bug_id=703
Are we deferring the second issue for now?
If so, we should probably put in a comment about it,
since it'll come up again eventually....