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.

Well, that definitely looks like a problem, but it may not be
the only one.  I tried applying your patch, recompiling, and
installing.  dhclient still seems to hang up on me.  This was
just a quick test, though, so I may have done something wrong.

In a later message, Dag-Erling Smørgrav wrote:
>Marcel Moolenaar <marcel at xcllnt.net> writes:
>>  This code is then obviously also broken on amd64 and ia64 [...]
>
>yep, if they have 64-bit time_t.

They do, but they are also different-endian.  Perhaps the bug
is not as serious in that case.  It could also be that the
people able to spend money on amd64 and ia64 can also afford
to have fixed IP addresses, and they don't run dhclient :-)

[or maybe they are running the version from /usr/ports]

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