getCPUTime implementation incorrect?

[Evan Laforge]

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 :)