Re: tar 1.19 - vms time_t is unsigned long. [partial patch[

[John E. Malmberg]

John E. Malmberg wrote:
> Eric Blake wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > According to John E. Malmberg on 3/8/2008 1:32 PM:
> > | I believe that this attached patch gets intprops.h TYPE_MAXIMUM to
> > | handle unsigned types.
> >
> > TYPE_MAXIMUM already handles unsigned types.  It seems like you have a
> > buggy compiler, instead.
>
> I should have re-read the comments in the module.

By default, time_t on VMS is unsigned, and I was trying to keep the 
assert from being tripped when building getdate, and I miss-diagnosed 
the issue.

And I forgot to back out the changes when I discovered that the assert 
was intentional when time_t is unsigned, to verify that they were still 
needed.

The reason I got misled is that on VMS, type long is 32 bits, but when 
math is being done, it is stored in a 64 bit register, and I thought 
that those extra 32 bits could be considered padding bits when doing the 
calculations in the macro.

> > |
> > | A mask is needed because of an extension that most C compilers have 
> > that
> > | allow ((unsigned int) -1)  to be tested as being less than 0 through
> > | operand promotion.
> >
> > Huh?  C99 6.3.1.8 states: "Otherwise, if the operand that has unsigned
> > integer type has rank greater or equal to the rank of the type of the
> <ship>
>
> Yes, I worded that wrong.  The compiler is fine in that regard, my 
> verbage was not that precise.

What I meant was that there are routines that are prototyped to return 
unsigned values, and that they return -1 on error, which does not appear 
to be a valid value for unsigned value.

And then the caller of that routine tests the result either against -1 
or to be less than 0 to verify that the routine succeeded as standard 
practice.

Unless some conversion is automatically done, an unsigned type tested 
for being less than 0 or equal to -1 would be expected to never be true.

And a lot of existing code would break.

This conversion is documented as an extension to the C standard in 
effect for the HP C V7 compiler, which is pre-C99.

http://h7100.www7.hp.com/commercial/c/docs/6180profile_018.html#index_x_663

e. 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 .

So it looks like with C99, it is no longer an optional extension for the 
compiler.

And currently my compiler is set to issue an informational diagnostic 
message every time it does one of the above comparisons.  I will start 
turning that off, since as you posted previously, it is no longer an 
optional extension.

But that is a side issue.

I will try to be more accurate in the future, but please keep in mind, 
my focus is trying to get this code to build and run, and I am not a 
"language lawyer".

> I did this change over 2 months to get things to compile.

> I will take my change out and recompile getdate to see if it is really 
> needed, and if it is, will look at the output.

I have verified that as long as I have time_t as a signed 32 bit long, 
getdate.c compiles with the original intprops.h

> But the real problem that I am having is getdate.y is throwing an assert 
> if time_t is an unsigned type.  And since my time_t is 32 bits, having 
> it signed introduces the Y2038 issue.

 Is there some way to change getdate.y to accept an unsigned time_t?

Thanks,
-John
address@hidden