This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2.2][BZ #12515] Improve precision of clock function
- From: Rich Felker <dalias at aerifal dot cx>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, Paul Eggert <eggert at cs dot ucla dot edu>, libc-alpha at sourceware dot org
- Date: Wed, 12 Jun 2013 16:27:01 -0400
- Subject: Re: [PATCH v2.2][BZ #12515] Improve precision of clock function
- References: <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> <51B66522 dot 1060008 at cs dot ucla dot edu> <20130611135422 dot GK8010 at spoyarek dot pnq dot redhat dot com> <20130611171952 dot EB3CF2C0A2 at topped-with-meat dot com> <20130612050307 dot GU8010 at spoyarek dot pnq dot redhat dot com> <20130612173819 dot 67B272C07E at topped-with-meat dot com> <20130612192718 dot GH19582 at spoyarek dot pnq dot redhat dot com>
On Thu, Jun 13, 2013 at 12:57:18AM +0530, Siddhesh Poyarekar wrote:
> + return (ts.tv_sec * CLOCKS_PER_SEC
> + + ts.tv_nsec / (1000000000 / CLOCKS_PER_SEC));
> }
What is the value of using CLOCKS_PER_SEC? There is a hidden
assumption here that CLOCKS_PER_SEC evenly divides 1000000000. It's
true since the standard requires CLOCKS_PER_SEC to be 1000000, but in
that case, I would think it makes more sense either to write out the
/1000, or to add a comment that CLOCKS_PER_SEC is 1000000 and thus the
arithmetic is safe, rather than leaving the reader wondering why
you're doing suspicious integer arithmetic that would not be correct
for arbitrary values of the macro.
Rich