From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23127 invoked by alias); 4 Nov 2004 23:53:57 -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 23111 invoked from network); 4 Nov 2004 23:53:57 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130) by sourceware.org with SMTP; 4 Nov 2004 23:53:57 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 656AB357B; Thu, 4 Nov 2004 15:53:56 -0800 (PST) Received: from magilla.sf.frob.com (localhost.localdomain [127.0.0.1]) by magilla.sf.frob.com (8.12.11/8.12.9) with ESMTP id iA4Nruqi029579; Thu, 4 Nov 2004 15:53:56 -0800 Received: (from roland@localhost) by magilla.sf.frob.com (8.12.11/8.12.11/Submit) id iA4NrtN1029576; Thu, 4 Nov 2004 15:53:55 -0800 Date: Thu, 04 Nov 2004 23:53:00 -0000 Message-Id: <200411042353.iA4NrtN1029576@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: davidm@hpl.hp.com Cc: libc-hacker@sources.redhat.com Subject: Re: second thoughts on using dl_iterate_phdr() for cache-validation In-Reply-To: David Mosberger's message of Thursday, 4 November 2004 15:41:39 -0800 <16778.48691.899903.792304@napali.hpl.hp.com> X-Shopping-List: (1) Barbarous cave dogs (2) Significant hydrants (3) Silent sagacious pretense retributions X-SW-Source: 2004-11/txt/msg00008.txt.bz2 No new ABI is going to go in very soon. We have frozen the GLIBC_2.3.4 ABI already. (Your patch adds symbols to a version set that has been fixed for a long time, which is never a kind of patch that would be accepted.) unsigned long long int is not an atomic type on all platforms, so your code as written is not acceptable without adding locking for machines where it's not. It seems preferable to just used unsigned long int instead, which it is safe to increment and examine simultaneously on all the platforms we have. An interface to return the address of such variables is highly dubious, since it constrains the implementation and does so permanently for the future.