Better handled integer overflow in isc_time_secondsastimet function

Michael Graff michael_graff at isc.org
Mon Jul 16 14:02:23 UTC 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Adam Tkac wrote:
> Hi,
> 
> recently I've got report that host's -w parameter doesn't work correctly
> (host die on timer.c:710: INSIST(result == 0 || result == 2) failed.).
> After investigation problem is in function which converts seconds to
> time_t (when time_t is 32bit signed value). Proposed patch is attached.
> 
> Adam

I would rather have the callers of this function know that the value
cannot fit and decide what to do than to make it return INT_MAX.  I
think the error is actually that we don't correctly check for range
issues when this function is called.  This is because some things which
mean "wait forever" really want to "wait for a very long time" while
others might want to use 0 there to mean "wait forever."

In the case of isc_cond_waituntil(), it should probably call
pthread_cond_wait() instead of pthread_cond_waituntil() with a very
large value.  For all practical purposes, though, MAX_INT seconds is
"forever" in this context.  I know if host doesn't return in 68 years
it's unlikely I'd keep on waiting for it.

explorer at not:~/proj/ISC/bind9-mainline> ./bin/dig/host -w isc.org
isc.org has address 204.152.184.88
isc.org has IPv6 address 2001:4f8:0:2::d
isc.org mail is handled by 15 mx.sth1.isc.org.
isc.org mail is handled by 10 mx.isc.org.

- --Michael


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFGm3pvZXirchfeIY0RAlhvAKDX6eH87gX/hJFxggWL4+5vJYlWSQCggfIa
nT+53UnDfDgvtCDeDV12A+c=
=Fm15
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: condition.c.diff
URL: <https://lists.isc.org/pipermail/bind-workers/attachments/20070716/96c9dc50/attachment.ksh>


More information about the bind-workers mailing list