Re: clock() function
Dan.Pop@cern.ch (Dan Pop) wrote in message news:<bm3j15$mu 7$6@sunnews.cer n.ch>...[color=blue]
> In <3f852bd2$0$274 72$91cee783@new sreader02.highw ay.telekom.at> "Robert Stankowic" <pcdoktor@netwa y.at> writes:
>
>[color=green]
> >Just one afterthought:
> >I could imagine, that the return value of clock() wraps if clock()
> >internally uses a counter of type clock_t, but is -1 if clock() internally
> >uses a type with a higher range.
> >But that is just a wild guess..
> >Anyone a more precise statement?[/color]
>
> The words: "the implementation' s best approximation" effectively mean that
> an implementation can return *anything* from a clock() call, including a
> negative value, without having its conformance affected.
>
> I would hope that an implementation as described by the OP (i.e. most
> Unix implementations ) constantly returns -1 after 36 minutes of CPU time,[/color]
No! Why would you hope that? To teach those of us who use
wraparounds a lesson?) In fact every system I know of use
wraparounds! This admittedly doesn't include all that many
systems but at least the common ones. It would be interesting
to hear about systems that don't do wraparounds (and at the
same time have a small clock type).
Given that one needs clock timings greater than 36 mins, how should
one achieve that? You could go for a non-C solution. That might get
messy though if you code for many platforms? (I have never chosen
that approach so I wouldn't know.) Or you could assume that clock()
works in the usual and IMO useful way, which IMO includes
wraparounds when they make sense, and use that to make some C
library that is fairly portable.
[color=blue]
> but I wouldn't bet on that.[/color]
I bet that there is a fair amount of C code using that clock() do
wrap around on systems where that has been common practice.
[color=blue]
> Especially after reading the Linux man page:
>
> BUGS
> ...
> Note that the time can wrap around. On a 32bit system
> where CLOCKS_PER_SEC equals 1000000 this function will
> return the same value approximately every 72 minutes.
>
> I've never needed to use clock() for intervals longer than a few minutes,
> so I've never tested its behaviour on overflow on any implementation.
>
> Most implementations provide better functions for this purpose, e.g. the
> Unix times (although it still uses clock_t, the conversion factor is no
> longer CLOCKS_PER_SEC, but sysconf(_SC_CLK _TCK), which has a reasonable
> value, reflecting the real resolution of these values).[/color]
But clock() with wraparounds is adequate, at least if you don't take
into account the nuisance of coding some library to take care of the
wraparounds and clock timings, which only needs to be done once
anyway.
Daniel Vallstrom
[color=blue]
>
> Dan[/color]
Dan.Pop@cern.ch (Dan Pop) wrote in message news:<bm3j15$mu 7$6@sunnews.cer n.ch>...[color=blue]
> In <3f852bd2$0$274 72$91cee783@new sreader02.highw ay.telekom.at> "Robert Stankowic" <pcdoktor@netwa y.at> writes:
>
>[color=green]
> >Just one afterthought:
> >I could imagine, that the return value of clock() wraps if clock()
> >internally uses a counter of type clock_t, but is -1 if clock() internally
> >uses a type with a higher range.
> >But that is just a wild guess..
> >Anyone a more precise statement?[/color]
>
> The words: "the implementation' s best approximation" effectively mean that
> an implementation can return *anything* from a clock() call, including a
> negative value, without having its conformance affected.
>
> I would hope that an implementation as described by the OP (i.e. most
> Unix implementations ) constantly returns -1 after 36 minutes of CPU time,[/color]
No! Why would you hope that? To teach those of us who use
wraparounds a lesson?) In fact every system I know of use
wraparounds! This admittedly doesn't include all that many
systems but at least the common ones. It would be interesting
to hear about systems that don't do wraparounds (and at the
same time have a small clock type).
Given that one needs clock timings greater than 36 mins, how should
one achieve that? You could go for a non-C solution. That might get
messy though if you code for many platforms? (I have never chosen
that approach so I wouldn't know.) Or you could assume that clock()
works in the usual and IMO useful way, which IMO includes
wraparounds when they make sense, and use that to make some C
library that is fairly portable.
[color=blue]
> but I wouldn't bet on that.[/color]
I bet that there is a fair amount of C code using that clock() do
wrap around on systems where that has been common practice.
[color=blue]
> Especially after reading the Linux man page:
>
> BUGS
> ...
> Note that the time can wrap around. On a 32bit system
> where CLOCKS_PER_SEC equals 1000000 this function will
> return the same value approximately every 72 minutes.
>
> I've never needed to use clock() for intervals longer than a few minutes,
> so I've never tested its behaviour on overflow on any implementation.
>
> Most implementations provide better functions for this purpose, e.g. the
> Unix times (although it still uses clock_t, the conversion factor is no
> longer CLOCKS_PER_SEC, but sysconf(_SC_CLK _TCK), which has a reasonable
> value, reflecting the real resolution of these values).[/color]
But clock() with wraparounds is adequate, at least if you don't take
into account the nuisance of coding some library to take care of the
wraparounds and clock timings, which only needs to be done once
anyway.
Daniel Vallstrom
[color=blue]
>
> Dan[/color]
Comment