malloc in gethostbyname

Luciano Rocha strange at nsk.no-ip.org
Tue Jun 10 12:33:56 UTC 2008


On Tue, Jun 10, 2008 at 01:59:54PM +0200, Bernd Schmidt wrote:
> For gethostbyname and related functions, I can see two alternatives to 
> just reverting to pre-uc_malloc state, either of which would enable us 
> to reduce the amount of static buffers.
> 
> Looking at some other C libraries, glibc still seems to use static 
> buffers, but in the FreeBSD C library, there is a dynamic allocation: 
> per thread, even, from what I can tell.  Of course they don't just exit 
> when it fails, but they return NULL from gethostbyXXX (without setting 
> h_errno or errno though, so it doesn't seem all that robust either).

errno should be set to ENOMEM by malloc itself when it fails.

> I had the idea of adding a config option that only leaves in the _r 
> variants of these functions and thus eliminates the static buffers. 
> While investigating this, I've hit a slight obstacle and discovered a 
> bug: getnameinfo, which is documented as one of the replacements for 
> gethostbyXXX, uses gethostbyaddr internally, which of course means that 
> it isn't reentrant.  In glibc, it uses temporary buffers on the stack 
> and calls gethostbyaddr_r.  We could do the same; the advantage would be 
> that we'd have reentrancy and we could ifdef out the non-reentrant 
> functions, but we'd also enlarge the stack requirements which is 
> unfortunate for nommu users.  OTOH, the other function in the pair, 
> getaddrinfo, already uses local buffers on the stack, so it's not 
> without precedent.
> 
> Comments?  Where should we go with this?

Personally, I'd go with something like the following, for functions that
may fail:

f() {
  __thread static *__buffer;

  if (!__buffer)
    __buffer = malloc();
  if (!__buffer)
    return F_ERR;
  return f_r(__buffer, ...)
}

-- 
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20080610/2857974d/attachment-0002.pgp 


More information about the uClibc mailing list