Problem with DHCLIENT vs 64-bit time_t

[Garance A Drosihn]

At 11:45 AM +0100 2/22/04, Dag-Erling Smørgrav wrote:
>Garance A Drosihn <drosih at rpi.edu> writes:
>>  So, there definitely is something wrong with the dhclient from
>  > the base system  But it might be that people having trouble
>  > with dhcp on 64-bTT sparc systems could use the port, at least
>  > for the short-term.
>
>Only takes a few minutes of eyeballing to figure out that the
>problem is most likely on line 424 of
>src/contrib/isc-dhcp/common/parse.c:
>
>         convert_num (cfile, (unsigned char *)timep, val, 10, 32);
>
>idiotically, the final argument to convert_num() is supposed to
>be the size in bits of the number to store in the location pointed
>to by the second argument.  The simplest fix is to use a temporary
>int32_t and assign it to *timep later, since convert_num() can't
>deal with 64-bit quantities.  See attached (untested) patch.

I added that patch, and it didn't help me.  I was also hoping
for some quick-fix to jump out at me, so I recompiled dhclient
on both i386 and sparc64 with 64-bTT after adding a whole bunch
of warning options to CFLAGS.  When I did this, I got over a
thousand warnings on both platforms...

On sparc, I noticed one warning:
     warning: cast from pointer to integer of different size
for
#ifdef PTRSIZE_64BIT
         icmp.icmp_id = (((u_int32_t)(u_int64_t)addr) ^
                         (u_int32_t)(((u_int64_t)addr) >> 32));      
#else
         icmp.icmp_id = (u_int32_t)addr;        <<<---- this line
#endif

I defined PTRSIZE_64BIT, and the client worked!!!  Well, it only
*thought* that it worked, so it went into the background instead
of just hanging.  But it didn't actually configure the interface,
so I reran it and this time it hung the same way it usually does.
Damn.  I thought I had something there.

When comparing the warnings from i386 to those from sparc64,
sparc64 sees about 50 extra warnings about:
     warning: cast increases required alignment of target type

Would this be a possible cause of inconsistent (and usually broken)
behavior in a program?  Do we need to try to fix all of those?

The only other "new warning" was:
     warning: `binding' might be used uninitialized in this function
at line 68 in function execute_statements in common/execute.c.
However, I couldn't see how that could be uninitialized, and I
couldn't see how the logic wrt that variable would *change* based
on platform, so I assume that's just a bogus warning.

Of course, our problems could easily be due to some of the other
1000 warnings...

-- 
Garance Alistair Drosehn            =   gad at gilead.netel.rpi.edu
Senior Systems Programmer           or  gad at freebsd.org
Rensselaer Polytechnic Institute    or  drosih at rpi.edu