This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: libc-time-clock test doesn't seem to be written correctly??
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