Better handled integer overflow in isc_time_secondsastimet function

[Adam Tkac]

Adam Tkac napsal(a):
> 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
could be "and substitute them by simple"
>
> if ( (res == ISC_R_RANGE) || (res == ISC_R_SUCCESS) ) ...
>
> Adam
>