[PATCH libevdev 5/5] Remove wrong libevdev clock test

[Peter Hutterer]

On Mon, Oct 07, 2013 at 01:01:05PM +0200, David Herrmann wrote:
> Hi Peter
> 
> On Sat, Oct 5, 2013 at 7:44 AM, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> > On 5/10/13 04:37 , David Herrmann wrote:
> >>
> >> We can rely on CLOCK_MONOTONIC and CLOCK_REALTIME to be different at any
> >> time. However, this does not apply to the ms/us/ns parts of the current
> >> time. Both may be in sync regarding the current micro-seconds state. So
> >> remove the wrong clock us-comparison.
> >>
> >> I was able to trigger this on my machine. Chances that both are in sync
> >> are very low so I assume my RTC only provides low granularity and thus
> >> both clocks are sync during boot for higher granularity.
> >>
> >> Signed-off-by: David Herrmann <dh.herrmann at gmail.com>
> >> ---
> >>   test/test-libevdev-init.c | 1 -
> >>   1 file changed, 1 deletion(-)
> >>
> >> diff --git a/test/test-libevdev-init.c b/test/test-libevdev-init.c
> >> index 7d4376d..c6adc40 100644
> >> --- a/test/test-libevdev-init.c
> >> +++ b/test/test-libevdev-init.c
> >> @@ -343,7 +343,6 @@ START_TEST(test_clock_id_events)
> >>         ck_assert_int_eq(ev1.value, ev2.value);
> >>
> >>         ck_assert_int_ne(ev1.time.tv_sec, ev2.time.tv_sec);
> >> -       ck_assert_int_ne(ev1.time.tv_usec, ev2.time.tv_usec);
> >
> >
> > IMO a better approach would be to calculate the full time as tv_sec *
> > 1000000 + tv_usec and then compare the two times.
> 
> Seems over-engineered to me. If the times really only differ in the
> "usec" part, then there's no reason for us to assume they're different
> at all. But comparing only "sec" is an implicit statement that we
> assume they differ quite a bit. And if they do, I think summing "sec"
> and "usec" up just makes it less readable and complicates things.

it's a test. it may look over-engineered but this is only run a few times,
and it's not performance-critical. if you want to make sure the times are
different, make sure they are really different rather than some 'arbitrary'
resolution. after all, we could also compare tv_sec/60 because the minute
should differ too, right? :) but now we're just arguing about what
resolution is good enough. and I say we have µs, so let's use µs.

Cheers,
   Peter