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