This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][BZ #12515] Improve precision of clock function
- From: Rich Felker <dalias at aerifal dot cx>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: Roland McGrath <roland at hack dot frob dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>, libc-alpha at sourceware dot org
- Date: Thu, 23 May 2013 16:25:37 -0400
- Subject: Re: [PATCH][BZ #12515] Improve precision of clock function
- References: <20130521145611 dot GM8927 at spoyarek dot pnq dot redhat dot com> <20130523192050 dot EBE582C09E at topped-with-meat dot com> <519E7461 dot 2010902 at cs dot ucla dot edu>
On Thu, May 23, 2013 at 12:56:17PM -0700, Paul Eggert wrote:
> On 05/23/13 12:20, Roland McGrath wrote:
> > Why do you think this is desireable? clock is an ancient interface and its
> > callers expect the tick-granularity behavior it's always had.
>
> My experience is the reverse: users of 'clock' are surprised
> by how bad its granularity is, and wish that 'clock' would behave
> as the patch proposes. See, for example:
Agreed. This question comes up quite often on stackoverflow too.
> http://www.guyrutenberg.com/2007/09/10/resolution-problems-in-clock/
>
> Admittedly 'clock' is an ancient and not-good interface, but
> it's unlikely that the proposed patch would break existing
> applications. The most common use for 'clock' is for portability
> to other operating systems, and portable applications typically
> aren't assuming a particular granularity.
Also, changing to using clock_gettime is necessary to fix bug #15524,
which I just posted:
http://sourceware.org/bugzilla/show_bug.cgi?id=15524
as the legacy times() approach has no way to determine if the result
overflowed.
Rich