This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] resolv: Allow new "timeout-ms" option


On Thu, Jun 21, 2012 at 10:42 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 06/21/2012 10:24 AM, Paul Stewart wrote:
>> I don't intend on changing the minimum timeout for the
>> entirety of glibc.
>
> Yes, of course, but my question was more the reverse:
> why should the use of RES_TIMEOUT_MS change the
> default timeout? ?Wouldn't it make more sense if
> RES_TIMEOUT_MS affects only the interpretation
> of the timeout field? ?That is, if the user specifies
> a negative timeout, which is obviously bogus,
> shouldn't the code silently adjust the timeout to 1 s
> regardless of whether RES_TIMEOUT_MS is specified?

Ah.  Good point.  So, the answer to that lies in what we're actually
limiting out to 1s (and RES_TIMEOUT_MS).  Is it really the user
specified value?  Under certain circumastances the value we check
"<=0" is actually (statp->retrans << ns) / statp->nscount.  Because I
couldn't guarantee under what conditions this value would be zero, it
didn't seem to me that the user specified a value less than zero every
time this inequality was satisfied.

> Is there a use case that indicates which is the better
> way to go here?

If indeed this condition only happens when the code is passed invalid
parameters, I'm flexible to just about any course. :-)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]