From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15605 invoked by alias); 30 Mar 2003 22:08:33 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 15587 invoked from network); 30 Mar 2003 22:08:33 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.160.55.131) by sources.redhat.com with SMTP; 30 Mar 2003 22:08:33 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id E6D78354C; Sun, 30 Mar 2003 14:08:31 -0800 (PST) Received: (from roland@localhost) by magilla.sf.frob.com (8.11.6/8.11.6) id h2UM8Vq32648; Sun, 30 Mar 2003 14:08:31 -0800 Date: Sun, 30 Mar 2003 23:33:00 -0000 Message-Id: <200303302208.h2UM8Vq32648@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Thorsten Kukuk Cc: Ulrich Drepper , libc-hacker@sources.redhat.com Subject: Re: AI_V4MAPPED/AI_ALL In-Reply-To: Thorsten Kukuk's message of Sunday, 30 March 2003 22:11:38 +0200 <20030330201138.GA25740@suse.de> X-Windows: flawed beyond belief. X-SW-Source: 2003-03/txt/msg00142.txt.bz2 > Ok, AI_V4MAPPED and AI_ALL are specified in POSIX, rfc2553 and > rfc3493. So I doubt that it will be changed in the near future > again, I think something specified in POSIX should be stable > enought to include in glibc. Agreed. I'm not sure the RFCs always indicate a stable interface, but what's in 1003.1-2001 we definitely want to implement and these are there. Can you add a test case that is broken by the current code and fixed by your patch? We can add an xtests case that requires some particular DNS zone data to do the test. At least for forward zone data, I can set up a glibc-test.gnu.org subdomain with test data if needed. > I append a patch which adds both defines to resolv/netdb.h and > implements it in getaddrinfo(). (Looking at the ugly getaddrinfo > code, it seems we really need a new, clean implementation :( ). Definitely true. It was close to the top of my list before you fixed the AF_UNSPEC behavior. I can probably find time before the next release to do the rewrite. If you have any list of known issues with the current implementation (aside from its internal structure), and especially if we can soup up the tests to cover more details, that would be a help. Thanks, Roland