Problem with DHCLIENT vs 64-bit time_t
Garance A Drosihn
drosih at rpi.edu
Sun Feb 22 20:17:03 PST 2004
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
> 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
icmp.icmp_id = (((u_int32_t)(u_int64_t)addr) ^
(u_int32_t)(((u_int64_t)addr) >> 32));
icmp.icmp_id = (u_int32_t)addr; <<<---- this line
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
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
More information about the freebsd-sparc64