[uClibc] clock() for long-running process

[Manuel Novoa III]

Hello,

On Sat, May 08, 2004 at 10:20:37PM +0900, Atsushi Nemoto wrote:
> >>>>> On Sat, 8 May 2004 00:18:49 -0600, mjn3 at codepoet.org (Manuel Novoa III) said:
> 
> mjn3> Checked a new version of the time code into cvs, including a
> mjn3> version of clock() which does wrapping.
> 
> Thank you.  New clock() now wraps on LONG_MAX (not ULONG_MAX).  I
> think this is somewhat unuseful.

I bitwise-and with LONG_MAX because the SUSv3 Application Notes state:
(from http://www.opengroup.org/onlinepubs/009695399/functions/clock.html)

  The value returned by clock() may wrap around on some implementations.
  For example, on a machine with 32-bit values for clock_t, it wraps
  after 2147 seconds or 36 minutes.

Hence the comment I included in the code.

> For example, this simple code will not work as expected if clock()
> wrapped.
> 
>  clock_t start, elapsed;
>  start = clock();
>  /* do some (not so long) work */
>  elapsed = clock() - start;

It would work as expected during the first 2147 seconds of _cpu_ time
(not wall clock time) used by the process.  After that, it would wrap
in a way you apparently wouldn't expect.  But then, you're making
unjustified assumptions about what it should do in that case because
the behavior is implementation defined.

> So I think we should not do bitwise-and with LONG_MAX.  And glibc's
> implementation do not do the bitwise-and operation.  How do you think?

Personally I thought it was better to return (clock_t)(-1) if wrapping
was detected, since that seems most consistent with the definition.
In fact, I think I'll go back to that approach unless someone can give
me a good reason not to.

As far as the difference between uClibc and glibc in this instance,
I would note it in the differences file.  But I'm against duplicating
glibc behavior here.  This is one of those instances where I'd prefer
to take a more strict interpretation of the standards.  glibc often
makes concessions for broken code, which is a practice I'm entirely
against.  All that does is hide program bugs that should be fixed.

Besides, you really shouldn't be using clock() to calculate elapsed
cpu time when times() is available.  The X/Open System Interfaces
Extension mandates that clock() values be scaled to millionths of a
second, which limits its usefulness on 32 bit systems for long-running
apps.

Manuel