TimeAmount.hours(.max) and probably others crash because of overflow

[weissi]

This may even be classified as a low severity security issue because someone may accept an hours number from a user and then do TimeAmount.hours(userProvidedValue). Not a good idea but you never know what users do.

Expected behavior

It should cap the amount to the maximum representable amount.

Actual behavior

My program crashes

Steps to reproduce

TimeAmount.hours(.max)

SwiftNIO version/commit hash

2.58.0

System & version information

macOS

[LorenzoFritzsch]

This issue was affecting all TimeAmount functions besides nanoseconds, as it was the only function that didn't do any arithmetical operations on the input amount. The other functions, on the other hand, converted the input amount to nanoseconds, and this led to overflowing in case the input amount was .max.
In order to avoid this TimeAmount(.max) is returned, in case the amount in nanoseconds overflows.

Here's an example from the PR:

@inlinable
public static func hours(_ amount: Int64) -> TimeAmount {
    let nanoseconds = amount &* (1000 * 1000 * 1000 * 60 * 60)
    return nanoseconds >= 0 ? TimeAmount(nanoseconds) : TimeAmount(.max)
}

[weissi]

This issue was affecting all TimeAmount functions besides nanoseconds, as it was the only function that didn't do any arithmetical operations on the input amount. The other functions, on the other hand, converted the input amount to nanoseconds, and this led to overflowing in case the input amount was .max. In order to avoid this TimeAmount(.max) is returned, in case the amount in nanoseconds overflows.

Here's an example from the PR:

@inlinable
public static func hours(_ amount: Int64) -> TimeAmount {
    let nanoseconds = amount &* (1000 * 1000 * 1000 * 60 * 60)
    return nanoseconds >= 0 ? TimeAmount(nanoseconds) : TimeAmount(.max)
}

Thanks for checking! Instead of using &* and a >= we should use multiplyingReportingOverflow which just tells us if it overflowed.