Digital clock in C - how to update the seconds? [closed] - c

Question

Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 3 years ago.
Improve this question
I was making a digital clock in C programming.
It takes input of current time from the user, then it updates the second to show the time in format HH:MM:SS.
I am confused with the part of for loop that is inside second.
for(i=0;i<8999990;i++)
i=i+1-1.
.
I have tried to dry run the code.
Suppose, I gave input 10:30:20 as hh:min:sec respectively.
Now, the for loop will start.
for loop for hr, then for loop for min, then for loop for sec...then for loop for i...
when sec is 20, for loop for i will run 89999990 times, and do i=i+1-1, ie update i value....
then sec will be 21....
what i am surprised of is how the "i" loop is creating an impact on the sec value?
and how that much fast?
[code]
#include<conio.h>
#include<stdio.h>
#include<stdlib.h>
int main()
{
int h=0,m=0,s=00;
double i;
printf("Enter time in format of HH MM SS\n");
scanf("%d%d%d",&h,&m,&s);
start:;
for(h;h<24;h++){
for(m;m<60;m++){
for(s;s<60;s++){
system("cls");
printf("\n\n\n\n\n\n\t\t\t\t\t\t%d:%d:%d\n",h,m,s);
for( i=0;i<89999900;i++){
i=i+1-1;
}
}
s=0;
}
m=0;
}
goto start;
}
[/code]

Answer 1

These kind of dirty "burn-away" loops were common long time ago, and still exist at some extent in embedded systems. They aren't professional since they are very inaccurate and also tightly coupled to a certain compiler build on a certain system. You cannot get accurate timing out of it for a PC, that's for sure.
First of all, programmers always tend to write them wrong. In the 1980s you could write loops like this because compilers were crap, but nowadays any half-decent compiler will simply remove that whole loop from the executable. This is because it doesn't contain any side-effects. So in order to make the code work at all, you must declare i as volatile to prevent that optimization.
Once that severe bug is fixed, you'll have to figure out how long time the loop actually takes. It is a sum of all CPU instructions needed to run it: a compare, some calculation and then increasing the iterator by 1. If you disassemble the program you can calculate this by adding together the number of cycles needed by all instructions, then multiply that with the time it takes to execute one cycle, which is normally 1/CPU frequency (ignoring pipelining, potential RAM access time losses, multicore etc etc).
In the end you'll come up with the conclusion that whoever wrote this code just pulled a number out of their... hat, then at best benchmarked the loop execution time with all optimizations enabled. But far more likely, I'd say this code was written by someone who didn't know what they were doing, which we can already tell from the missing volatile.

Answer 2

You should not use goto. To have an infinite loop, you can use a while(1) loop as shown.
You should use the system provided sleep or delay function. rather than writing your own for loop. This is because the no of iterations will change if you go to a different machine.
The program given below is a crude clock and will accumulate delays, as there will be some time required for execution of the code which is not considered during the design.
The code given below is assuming linux sleep function, for windows sleep function you can refer Sleep function in Windows, using C. If you are using an embedded system, there will be delay functions available, or you can write your own using one of the timers.
while(1)
{
for(h;h<24;h++)
{
for(m;m<60;m++)
{
for(s;s<60;s++)
{
system("cls");
printf("\n\n\n\n\n\n\t\t\t\t\t\t%d:%d:%d\n",h,m,s);
sleep(1000);
}
s=0;
}
m=0;
}
h = 0;
}