From owner-freebsd-current@FreeBSD.ORG Sun Jun 15 19:46:19 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BDC937B401; Sun, 15 Jun 2003 19:46:19 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61B4743FCB; Sun, 15 Jun 2003 19:46:18 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38ldt8g.dialup.mindspring.com ([209.86.245.16] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19Rk0d-0006d2-00; Sun, 15 Jun 2003 19:46:16 -0700 Message-ID: <3EED2F36.91132A4E@mindspring.com> Date: Sun, 15 Jun 2003 19:45:10 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kris Kennaway References: <20030616015459.GA35478@rot13.obsecurity.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a47573cb5d55b400de5ff1695801cd8c5ba2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c cc: julian@FreeBSD.org cc: current@FreeBSD.org Subject: Re: Bogus "temporary" gethostbyaddr_r() in libc for 6 years X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2003 02:46:19 -0000 Kris Kennaway wrote: > There's a bogus implementation of gethostbyaddr_r() in > lib/libc/net/gethostnamadr.c that was committed 6 years and nine > months ago: [...] > What's the deal here? Despite the fact that this is not prototyped in > a header, some ports are detecting this, and -- one assumes -- not > behaving correctly since this implementation isn't thread-safe. It should be removed. It's really hard to write a multithreaded version of this function, since it's essentially a request/response protocol. The most correct implementation would use a seperate worker thread and queue requests to it. -- Terry