Better handled integer overflow in isc_time_secondsastimet function

[Adam Tkac]

Michael Graff napsal(a):
>
> 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
>   

Sounds fine. But I think isc_time_secondsastimet could return 
ISC_R_RANGE and set time_t to maximum (or minimum if this situation 
occurs) possible value. This could avoid statements like

if (result == ISC_R_RANGE)
  time_t = maxval;
if (result == ISC_R_SUCCESS)

and simple

if ( (res == ISC_R_RANGE) || (res == ISC_R_SUCCESS) ) ...

Adam