Hi,
On 14 February 2017 at 14:24, Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Tue, 14 Feb 2017 13:18:02 +0000
> Daniel Stone <dani...@collabora.com> wrote:
>> +/* Add a millisecond value to a timespec
>> + *
>> + * \param r[out] result: a + b
>> + * \param a[in] base operand as timespec
>> + * \param b[in] operand in milliseconds
>> + */
>> +static inline void
>> +timespec_add_msec(struct timespec *r, const struct timespec *a, int64_t b)
>> +{
>> + r->tv_sec = a->tv_sec + (b / 1000);
>> + r->tv_nsec = a->tv_nsec + ((b % 1000) * 1000000);
>> +
>> + if (r->tv_nsec >= NSEC_PER_SEC) {
>> + r->tv_sec++;
>> + r->tv_nsec -= NSEC_PER_SEC;
>> + } else if (r->tv_nsec <= -NSEC_PER_SEC) {
>
> The same problem as with the previous patch, tv_nsec cannot be allowed
> negative.
Same rationale. In particular, this is used later in the series to
subtract repaint_window from the timespec.
>> + r->tv_sec--;
>> + r->tv_nsec += NSEC_PER_SEC;
>> + }
>> +}
>
> Any reason to not write this as a call to timespec_add_nsec()?
> The testing added below is very thin otherwise.
I think the rationale was to try to avoid overflow in super
pathological cases. But I'm not really attached to enormous
millisecond input values, so could just trivially reimplement it on
top of the _nsec variant.
Cheers,
Daniel
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
