Casting (time_t)(-1)

[Dave Sinkula]

I have been told conflicting advice. Please offer comments regarding the
following.

=====

I visited Ben Pfaff's "When are casts appropriate?" page.
http://www.msu.edu/~pfaffben/writings/clc/casts.html

I mentioned to Ben Pfaff that a potential addition of an appropriate use of
a cast was when comparing to the result of the time() function (and another
instance not mentioned here).

#include <stdio.h>
#include <time.h>

int main(void)
{
time_t now = time(NULL);
if ( now != (time_t)-1 )
{
fputs(ctime(&now), stdout);
}
return 0;
}

-----

The response I received from Ben Pfaff was as follows:

I can't see why a cast is necessary there either; time_t is an arithmetic

type.

=====

Later, I passed this along and received this response:

-----

There isn't anything stopping an implementation from using, say, unsigned
char for time_t. Since the C standard specifies that time returns
(time_t)(-1), which would be promoted to 255 on many systems, the test
against unqualified -1 would fail to give correct results:

#include <stdio.h>

typedef unsigned char my_t;

int main ( void )
{
my_t t = (my_t)(-1);

if ( t == -1 )
printf ( "Equal\n" );
else
printf ( "Not equal\n" );
if ( t == (my_t)-1 )
printf ( "Equal\n" );
else
printf ( "Not equal\n" );
}

I don't know of any implementations where this would be an issue, but to be
strictly correct, the cast should be used. In fact, the standards committee
ended up correcting the mktime example in the standard when they realized
this because it originally used -1 without a cast.

-----

I relayed this to Ben Pfaff for comment, and he requested that I bring it up
here.

So here I am, and I believe the question is, "Can (or should) the value
returned by time() be compared to an unadorned -1, or is it appropriate to
use a cast and compare to (time_t)(-1)?"

 

[Leor Zolman]

There isn't anything stopping an implementation from using, say, unsigned
char for time_t. Since the C standard specifies that time returns
(time_t)(-1), which would be promoted to 255 on many systems, the test
against unqualified -1 would fail to give correct results:

This is a rather interesting issue--two things jump out at me, however,
that make me suspect that the "unsigned char" mentioned above might not in
fact be of the 8-bit variety. First: the C Standard, in 7.23.1/3, says that
time_t (along with clock_t) are
"arithmetic types capable of representing times"
I'm sorry, I just don't see a /8-bit/ unsigned char representing times, by
any stretch of the imagination.

Second: One of the first thing one learns from hanging around this group
for a while is that "bytes" need not be limited to 8 bits; thus, the
smallest addressable chunk of memory /could/ be, say, 32 or 36 bits on some
hardware platform, and thus chars would be at least that size...and that
would be sufficient to represent times. So, indeed, those could be signed
or unsigned by default, and perhaps that's the scenario that convinced the
committee to cast those -1's to time_t "just in case". (My guess is that
ints would end up the same size as chars on those kinds of platforms,
though, and it would seem that the issue could be totally avoided by
typedef-ing time_t to be int instead of unsigned char, but since I'm
already way into subjects in which I have no direct experience, I will now
shut up.)
-leor


Leor Zolman
BD Software
(e-mail address removed)
www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
Decryptor at www.bdsoft.com/tools/stlfilt.html

 

[Jack Klein]

I have been told conflicting advice. Please offer comments regarding the
following.

=====

I visited Ben Pfaff's "When are casts appropriate?" page.
http://www.msu.edu/~pfaffben/writings/clc/casts.html

I mentioned to Ben Pfaff that a potential addition of an appropriate use of
a cast was when comparing to the result of the time() function (and another
instance not mentioned here).

#include <stdio.h>
#include <time.h>

int main(void)
{
time_t now = time(NULL);
if ( now != (time_t)-1 )
{
fputs(ctime(&now), stdout);
}
return 0;
}

-----

The response I received from Ben Pfaff was as follows:

type.

=====

Later, I passed this along and received this response:

-----

There isn't anything stopping an implementation from using, say, unsigned
char for time_t. Since the C standard specifies that time returns
(time_t)(-1), which would be promoted to 255 on many systems, the test
against unqualified -1 would fail to give correct results:

#include <stdio.h>

typedef unsigned char my_t;

int main ( void )
{
my_t t = (my_t)(-1);

if ( t == -1 )
printf ( "Equal\n" );
else
printf ( "Not equal\n" );
if ( t == (my_t)-1 )
printf ( "Equal\n" );
else
printf ( "Not equal\n" );
}

I don't know of any implementations where this would be an issue, but to be
strictly correct, the cast should be used. In fact, the standards committee
ended up correcting the mktime example in the standard when they realized
this because it originally used -1 without a cast.

-----

I relayed this to Ben Pfaff for comment, and he requested that I bring it up
here.

So here I am, and I believe the question is, "Can (or should) the value
returned by time() be compared to an unadorned -1, or is it appropriate to
use a cast and compare to (time_t)(-1)?"

I would use the cast, even though it is most likely not necessary.

Likewise, if I were to do something foolish, or use a library that did
something foolish, that used -1 in a size_t to indicate something, I
would do the comparison as (size_t)-1.

The entire point of using portable, opaque types is not to think about
their representation and its promotions/conversions. That rather
defeats the purpose.

 

[Ben Pfaff]

So here I am, and I believe the question is, "Can (or should) the value
returned by time() be compared to an unadorned -1, or is it appropriate to
use a cast and compare to (time_t)(-1)?"

Given the example of time_t as unsigned char, it seems reasonable
to include the cast. I wasn't thinking of that possibility at
the time of my original response.

(However, an 8-bit unsigned char couldn't usefully represent a
time, so time_t could probably be unsigned char only on a system
with a very wide unsigned char.)

 

[Dan Pop]

There isn't anything stopping an implementation from using, say, unsigned
char for time_t.

Actually, there is: it's called the quality of implementation factor.

Since the C standard specifies that time returns
(time_t)(-1), which would be promoted to 255 on many systems, the test

Such systems could only represent 255 time values (and the error flag
value). The quality of implementation factor of such an implementation
would be so small that practically no one would want to use it.

against unqualified -1 would fail to give correct results:

This is right, so portable C code has NO excuse for omitting the cast,
considering that it has no adverse effects in terms of readability,
maintainability or run time overhead.

More importantly, however, the cast actually improves the code
readability, regardless of whether it is realistically necessary or not.
In its absence, the reader would have to consider in what cases -1 is
converted to time_t and in what cases time_t is converted to int and
whether this has any effect on the result of the comparison. The cast
simply clarifies the issue and renders any analysis superfluous.

Well spotted example of a case where it's better to use a cast.

Dan