>>All I find...
What you find has absolutely nothing to do with what the standard says.
Here's how one would continue this argument:
- Buy a copy of the standard.
- Read it.
- Assert your interpretations of the standard that support your argument.
Otherwise, read the links provided in this thread and drawn your own conclusions. Here's mine: "If you don't care about portability or adhering to the standard, then do whatever works".
Nothing to do with the standard??? Ok then maybe I've been posting MS specific code or something without knowing...
But you still haven't presented that link to justify your opinion... Do that and I'll believe you.
And I have a copy of the standard (pdf though). Let me quote it:
typedef long time_t;
I understand perfectly what you're saying but, I've never eared or readed anything about time_t not being arithmetic. There are non arithmetic types like struct tm.
>> Let me quote it:
How bout a real qoute will some section numbers etc.
Then what you'll want to do is explain how the quote supports your argument.
I've done that, you didn't...
Try looking in the time.h section
Does the standard really define the implementation of the standard library functions? I was under the impression that it only defined the behaviour - in which case it is likely that the time.h that you are referring to (I'm assuming that you're looking at a header file and not an explicit statement of how the time_t must be defined) is only an example of how time.h might be implemented, and is not binding for those who wish to implement the standard in their own compilers.
Well, I usually try to teach folks how to fish, but some just need to be spoon fed…..here's how you quote the standard:
This is from C99 but applies equally to C89.
From: ISO/IEC 9899:1999 (E)
7.23 Date and time <time.h>
7.23.1 Components of time
3 The types declared are size_t (described in 7.17);
clock_t and time_t which are arithmetic types capable of representing
times; and struct tm which holds the components of a calendar time,
called the broken-down time.
188.8.131.52 The time function
1 #include <time.h>
time_t time(time_t *timer);
2 The time function determines the current calendar time. The encoding of
the value is unspecified.
3 The time function returns the implementation’s best approximation to
the current calendar time. The value (time_t)(-1) is returned if the
calendar time is not available. If timer is not a null pointer, the
return value is also assigned to the object it points to.
There's a big difference between arithmetic properties (my original post) and an arithmetic type. The standard defines time_t as arithmetic type so that a comparison to (time_t)(-1) can be made. More importantly, the encoding of the time value is not defined. Meaning it could be seconds, micro-seconds, nano-seconds, or none of the above. The encoding doesn't even have to be in any unit of time, it could be a binary encoded decimal (BCD) of date/time values (adding 20 to a BCD doesn't make any sense).
Under ISO C, time_t is an abstract type for which the only valid arithmetic operation is comparison to (time_t)(-1).
As a side note, under the Single Unix Specification (the current POSIX standard), the time_t value returned by the time() function is defined to be in units of seconds. This is the most common implementation I've seen over the years.
So, (once again) if you're not concerned with portability of source code under ISO C, simply follow the documentation that came with your standard C library implementation. As a contributor to these forums, I'm simply following the convention of pointing out what is standard and what isn't standard (as far as I understand it).
I prefer "boo-yaa" over "busted" ;)