Bring back conversion of process CPU time on macOS (#1638)

[erikolofsson]

Fixes #1638

[Explorer09]

I don't have any more comment with this code now. But perhaps is good to explain what's the difference between this PR and #1643. Does this supersede #1643?

Cc @aestriplex

[Explorer09]

   assert(ticks_quot <= UINT64_MAX / Platform_nanosecondsPerMachTickNumer);
   assert(Platform_nanosecondsPerMachTickDenom <= UINT64_MAX / Platform_nanosecondsPerMachTickNumer);

These two constraints are what prevent the overflow from happening in this function. Not sure if these two assertions are worth adding into the function, but I mention these just for completeness sake.

The first assertion is related to a time overflow (like Y2K) that might be out of scope of htop.
The second assertion can always hold true when mach_timebase_info_data_t uses 32-bit integers for both numerator and denominator fields.

[BenBE]

They don't exactly hurt, but given this is what ultimately gives the time values used in htop, they should not straight up cause htop to terminate seemingly at random. Instead normal handling that causes a runtime warning (once) could be done instead …

Can you elaborate on the intuition of the second assertion?

[Explorer09]

@BenBE

ticks_rem < Platform_nanosecondsPerMachTickDenom ;
ticks_rem * Platform_nanosecondsPerMachTickNumer < Platform_nanosecondsPerMachTickDenom * Platform_nanosecondsPerMachTickNumer
(or Platform_nanosecondsPerMachTickNumer == 0)

When Platform_nanosecondsPerMachTickDenom * Platform_nanosecondsPerMachTickNumer is less than 2^64, ticks_rem * Platform_nanosecondsPerMachTickNumer will be less than 2^64 as well, i.e. never overflows.

[erikolofsson]

Do you want me to do any changes?

The overflow should only happen when the result in nano-seconds overflows, which would already be a problem in other places in the application. This is after 584 CPU-years.

[BenBE]

Optional. I mostly asked for some clarifications here.

If you decided to update the PR, be sure to avoid direct asserts (for the reasons mentioned above), and instead choose a way that is as obvious as possible, that this is some intentional error value.

[Explorer09]

@erikolofsson My view is that the time overflow bug that would happen 584 years later (the overflow on part1) is out of scope, but without an in-code comment, the (ticks_rem * Platform_nanosecondsPerMachTickNumer) in part2 can be mistaken as prone to overflow. (It actually doesn't overflow for the reason I stated above.)