getCPUTime implementation incorrect?

[Simon Marlow]

On 31/05/2011 04:37, Evan Laforge wrote:
> I've just noticed that getCPUTime is returning erratic results for me:
>
> GHCi, version 7.0.3: http://www.haskell.org/ghc/  :? for help
> Loading package ghc-prim ... linking ... done.
> Loading package integer-gmp ... linking ... done.
> Loading package base ... linking ... done.
> Loading package ffi-1.0 ... linking ... done.
> Loading package filepath-1.2.0.0 ... linking ... done.
> Prelude>  :m System.CPUTime
> Prelude System.CPUTime>  getCPUTime
> 9696631700340362000000
> Prelude System.CPUTime>  getCPUTime
> 1333572622260398592000000
> Prelude System.CPUTime>  getCPUTime
> 21577331579851694000000
> Prelude System.CPUTime>  getCPUTime
> 21577331579861838000000
> Prelude System.CPUTime>  getCPUTime
> 1061231477620269514000000
> Prelude System.CPUTime>  getCPUTime
> 9965140170836829000000
>
> This is ghc 7.0.3, OS X 10.6.7, and it's the x86_64 version downloaded
> from http://www.haskell.org/ghc/download_ghc_7_0_3
>
> So, I looked at the CPUTime.hsc source in the base library, and it
> uses CTime to get tv_sec and tv_usec fields from the struct timeval.
> Unfortunately, and I never knew this, tv_usec is not time_t, but is
> suseconds_t.  On my OS X, these are different types: time_t is 64 bits
> but suseconds_t is 32 bits.  After writing my own getCPUTime that uses
> Int32 for tv_usec it's back to working again.
>
> But the proper way to do this is probably to introduce CSUSeconds (I'm
> guessing it stands for signed microseconds), which I guess means
> editing the autoconfig to put a new define in HsBaseConfig.h.  I dont
> know anything about autoconfig, but it's probably easy enough for
> someone is :)

See

   http://hackage.haskell.org/trac/ghc/ticket/4247

and

   http://hackage.haskell.org/trac/ghc/ticket/4970

We ought to fix this in 7.0.4, since getCPUTime is pretty broken on OSX 
64-bit right now, but the fix involves an API change (to 
Foreign.C.Types).  Ian - could we apply a fix that doesn't change APIs?

Cheers,
	Simon