Date: Sun, 22 Feb 2004 23:16:58 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= ) Cc: sparc64@freebsd.org Subject: Re: Problem with DHCLIENT vs 64-bit time_t Message-ID: <p06020476bc5f2b073f02@[128.113.24.47]> In-Reply-To: <xzpznbbwfxb.fsf@dwp.des.no> References: <p06020407bc533f0ae9d2@[128.113.24.47]> <20040215060047.GA62840@dhcp01.pn.xcllnt.net> <p0602040ebc54c885236b@[128.113.24.47]> <20040215165913.M30161@grogged.dyndns.org> <p06020425bc571c20bcde@[128.113.24.47]> <p06020466bc5e09bf7182@[128.113.24.47]> <xzpznbbwfxb.fsf@dwp.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
At 11:45 AM +0100 2/22/04, Dag-Erling Smørgrav wrote:
>Garance A Drosihn <drosih@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@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p06020476bc5f2b073f02>