Bug 1888 - time.c - An unsigned time_t type should never be equal to -1
time.c - An unsigned time_t type should never be equal to -1
Status: CLOSED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: Build environment
3.0.7
Alpha OpenVMS
: P3 normal
: none
Assigned To: Tim Potter
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-07 20:48 UTC by John Malmberg
Modified: 2005-08-24 10:27 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Malmberg 2004-10-07 20:48:19 UTC
In the module time.c,

In the routines unix_to_nt_time(), unix_to_nt_time_abs(),

Comparisons are being made with a time_t type to see if it is -1.

On a platform where time_t is unsigned, it can never have a negative value.

Some C compilers have an extension where they will promote the -1 to be an
unsigned type with all bits set to make this work, but I would recommend putting
a cast of (time_t) on these comparisons just to make sure that these conversions
work, as from a logical point of view, any comparison of an unsigned value with
a negative number should always be false.
Comment 1 Tim Potter 2004-10-10 04:38:54 UTC
Link to bug #1894.
Comment 2 Tim Potter 2004-10-10 04:43:17 UTC
Ugh - why did I link to bug #1894.  Delete it.

John, it appears that, according to
http://www.opengroup.org/onlinepubs/009695399/functions/mktime.html, that
mktime() returns -1 on error, implying that -1 can be assigned to a variable of
time_t.

What does VMS return in an error situation?
Comment 3 John Malmberg 2004-10-10 07:17:36 UTC
What has been run into here is where the "standards" have a ambiguity.

While the mktime() returns a -1 on error, that value can not be represented in a
time_t type that is unsigned.

When -1 is cast with a (time_t), then the conversion can be expected as to what
is done with the mktime() function.


In the case of the VMS HP C compiler, it documents as an EXTENSION to the ANSI
standard:

"# Otherwise, if one operand has type long int  and the other has type unsigned
int , and if a long int  can represent all values of an unsigned int , the
operand of type unsigned int  is converted to long int . If a long int  cannot
represent all the values of an unsigned int , both operands are converted to
unsigned long int ."


When the compile is done with a /warning=enable=(questcode, level4), which is
effectively a LINT mode, the compiler flags the use of that extension as it is
counter intuitive of what explictily requested.

I suspect that most platforms have such an extension.  I remember reading
somewhere that GCC by design at one time ignored all sign/unsigned mismatches
even where the standard required a diagnostic message.

What I have noticed is that in most cases of the SAMBA code where this type of
condition could occur, a cast is present.  These are the few cases where the
cast is not present.
Comment 4 Tim Potter 2005-08-02 13:37:46 UTC
Hi John.  OK I've gone through and added casts in appropriate places to close
out this bug.
Comment 5 Gerald (Jerry) Carter 2005-08-24 10:27:19 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.