By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,682 Members | 1,013 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,682 IT Pros & Developers. It's quick & easy.

Casting (time_t)(-1)

P: n/a
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)?"


Nov 14 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
On Tue, 02 Mar 2004 03:43:29 GMT, "Dave Sinkula"
<Da**********@worldnet.att.net> wrote:
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
le**@bdsoft.com
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
Nov 14 '05 #2

P: n/a
On Tue, 02 Mar 2004 03:43:29 GMT, "Dave Sinkula"
<Da**********@worldnet.att.net> wrote in comp.lang.c:
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)?"


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.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Nov 14 '05 #3

P: n/a
"Dave Sinkula" <Da**********@worldnet.att.net> writes:
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.)
--
"The fact that there is a holy war doesn't mean that one of the sides
doesn't suck - usually both do..."
--Alexander Viro
Nov 14 '05 #4

P: n/a
In <Bp*********************@bgtnsc04-news.ops.worldnet.att.net> "Dave Sinkula" <Da**********@worldnet.att.net> writes:
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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.