time_t data type-- what does start +1 mean?

Hi,
I am trying to understand an very old C program.

....
time_t start, end;
ptr = localtime(&start);
...
fprintf(out, "%-35s 01 %5s %2s %10d 1 5 /tty/M%d/%02d %24s", buffer3, job, ver, start, mach_num,atoi(buffer), asctime(ptr));

fprintf(out, "%-35s 03 %5s %2s %10d 1 5 /tty/M%d/%02d %24s", buffer3, job, ver, (start + 1), mach_num,atoi(buffer), asctime(ptr));
.....

what does (start+1) do here?
What about asctime(ptr)?

Thanks a lot!!

.

May I make a suggestion? asctime() is part of the standard C library, so the man page

man asctime

will tell you everything you need to know.

start+1 just displays one more than the unsigned long value of start.

Hi
I kind of understood the meaning for those two questions but just wanted to verify it.

Here is the my real problem:
When the below code running, sometimes the result of end-2 is greater than end -1, sometime it isn't.

Does anyone know what could be the reason?

Thanks a lot!

.....
time_t start, end;
.....
fprintf(out, "%-35s 55 %5s %2s %10d 1 5 /tty/M%d/%02d %24s", buffer3, job, ver, end - 2, mach_num,atoi(buffer), asctime(ptr));

fprintf(out, "%-35s 50 %5s %2s %10d 1 5 /tty/M%d/%02d %24s", buffer3, job, ver, (end - 1), mach_num,atoi(buffer), asctime(ptr));

What you've posted so far doesn't give enough information. Are there any intervening lines between the two fprint() statements?

This looks like an attempt to check time sync on two different boxes.

No, there is no intervening lines between the two fprint() statements.
But this is this : ptr = localtime(&end);

I know that this part of the code suppose to write to a log file format like below. But sometimes the number with blue color in the second line is lesser than the number with blue in the first line. The number should be the seconds after 1970. It happened randomlly.

6174 Name 55 20261 02 1110798898 1 5 /tty/M1/08 Mon Ma
r 14 06:15:00 2005
6174 Name 50 20261 02 1110798002 1 5 /tty/M1/08 Mon Ma
r 14 06:15:00 2005

5514 Name 55 00000 03 1126647298 1 5 /tty/M1/03 Tue Sep 13 17:35:00 2005
5514 Name 50 00000 03 1126647299 1 5 /tty/M1/03 Tue Sep 13 17:35:00 2005

Under some heavy-duty circumstances and with some versions of unix:
the order that data is written to a file may not be preserved. We had an old DEC-unix box that did that. I don't know that this is what you are seeing, but it's possible.

You can correct the problem with fflush():

fprintf(..........);
fflush(out);
fprintf(...........);

This has nothing to do with C in particular.

Jim,
According to your reason: the difference between the first data and second data will be around 15 minutes behind. Could it be that long?
1110798898-1110798002=896 seconds

6174 Name 55 20261 02 1110798898 1 5 /tty/M1/08 Mon Mar 14 06:15:00 2005
6174 Name 50 20261 02 1110798002 1 5 /tty/M1/08 Mon Mar 14 06:15:00 2005

I am thinking maybe it's the parenthesis cause the trouble???
"end -2" without parenthesis calculated the time correctly.
But "end -1" with the parenthesis didn't calculated time correctly sometimes.

It doesn't make sense to me since I thought with the parenthesis should be getting the correct answer.

Does it really matter with parenthesis or without parenthesis?

fprintf(out, "%-35s 55 %5s %2s %10d 1 5 /tty/M%d/%02d %24s", buffer3, job, ver, end - 2, mach_num,atoi(buffer), asctime(ptr));

fprintf(out, "%-35s 50 %5s %2s %10d 1 5 /tty/M%d/%02d %24s", buffer3, job, ver, (end - 1), mach_num,atoi(buffer), asctime(ptr));

I don't know all of what is going on.

No, the parentheses are not a problem at all. If you personally think it's a problem then remove them. It won't hurt. Any modern C compiler will evaluate (end - 2) and end - 2 as the same thing. Parenthetic expressions are evaluated first. In some old compilers you needed (x - 2) to force it to evaluate the expression, pre-C89.

Well, if it should not matter, I will keep the parenthesis there for now beause the problem is not always presented.
I will add fflush(out); betweeen these two lines and see if the problem come back again.

Thank you so much for the help!

I don't see a problem with the code that posted, but I would try a different variable name than "end" just to be sure. "end" is very special on most systems. Try "man end", you probably have a man page on it.