EAGAIN on older (correct) glibc versions indicate a problem and not the need

for a bigger buffer and this is indeed badness for us. Making this work
on both old and new glibc versions require an ugly loop that in its worse
form cause 45 bad loops when using the correct glibc and a non-resolving
host name... :-/

We want a better fix. Badly.
This commit is contained in:
Daniel Stenberg 2002-12-16 11:33:44 +00:00
parent 96d84150e1
commit e879e26a5b
1 changed files with 16 additions and 4 deletions

View File

@ -631,16 +631,28 @@ static Curl_addrinfo *my_getaddrinfo(struct SessionHandle *data,
&h, /* DIFFERENCE */
&h_errnop);
/* Redhat 8, using glibc 2.2.93 changed the behavior. Now all of a
sudden this function seems to be setting EAGAIN if the given buffer
size is too small. Previous versions are known to return ERANGE for
the same. */
sudden this function returns EAGAIN if the given buffer size is too
small. Previous versions are known to return ERANGE for the same
problem.
This wouldn't be such a big problem if older versions wouldn't
sometimes return EAGAIN on a common failure case. Alas, we can't
assume that EAGAIN *or* ERANGE means ERANGE for any given version of
glibc.
For now, we do that and thus we may call the function repeatedly and
fail for older glibc versions that return EAGAIN, until we run out
of buffer size (step_size grows beyond CURL_NAMELOOKUP_SIZE).
If anyone has a better fix, please tell us!
*/
if((ERANGE == res) || (EAGAIN == res)) {
step_size+=200;
continue;
}
break;
} while(1);
} while(step_size <= CURL_NAMELOOKUP_SIZE);
if(!h) /* failure */
res=1;