[ECOS] libc-time-clock test doesn't seem to be written correctly??

[Jonathan Larmour]

sandeep wrote:
> 
> then following change will achieve more correctly and closely what you 
> have mentioned above i.e. -- "how long it takes for the return value of 
> clock() to change".
> 
> static unsigned long
> clock_loop( const int timeout, clock_t prevclock, clock_t *newclock )
> {
>     clock_t c=0;
>     long i;
> 
> // ++++++++++++++++
> 
>     c = clock();
>     while ((prevclock = clock()) == c) /* do nothing */ ;
> 
>     // now when we enter the for-loop below, clock() value has just changed

No need. That synchronization is already done by virtue of this function 
itself being called in a tight loop and the first few results discarded 
(the SKIPPED_SAMPLES in the test). So when this function returns, clock() 
will still have "just changed" and the function is then immediately called 
again. If nothing else, there are a consistent number of instructions 
between calls to clock().

> // ???????????????
> // why should following be a fail condition in test where we are trying to
> // check for clock stability
> // ???????????????
> 
> // NRN-start : Not Really Needed, in the view of what test is aiming at
> 
>     // it should not overflow in the lifetime of this test
>     if (c < prevclock)
>         CYG_TEST_FAIL_FINISH("Clock decremented!");
> 
>     *newclock = c;
> 
> // NRN-end

It's a test, and testing for stability is the main goal but not the only 
one. Let's test for things that shouldn't happen.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss