From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19331 invoked by alias); 8 Apr 2010 23:42:40 -0000 Received: (qmail 19315 invoked by uid 22791); 8 Apr 2010 23:42:40 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 08 Apr 2010 23:42:35 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o38NgN5W022374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Apr 2010 19:42:23 -0400 Received: from myware71.akkadia.org (vpn-236-205.phx2.redhat.com [10.3.236.205]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o38NgFQ3003022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Apr 2010 19:42:18 -0400 Message-ID: <4BBE69D7.7030009@redhat.com> Date: Thu, 08 Apr 2010 23:42:00 -0000 From: Ulrich Drepper User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.4 MIME-Version: 1.0 To: Andreas Schwab CC: libc-hacker@sourceware.org Subject: Re: [PATCH] Don't call uname or getrlimit in libpthread init function References: <4BBE5A73.9080600@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Mailing-List: contact libc-hacker-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sourceware.org X-SW-Source: 2010-04/txt/msg00007.txt.bz2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/08/2010 04:16 PM, Andreas Schwab wrote: > The last time I checked, uname was not in C99. Neither is POSIX threads. If you link with the DSO you're leaving ISO C territory. And moreover: when you define a function umask in your program (= the executable) nothing bad will happen. Preloading, as in this case, is something completely different. This is just another precedence for somebody doing stupid things and expecting nothing to break. It's just a bad idea to encourage this. If you replace a function then do it right and everything will work correctly. If the floodgates for these kinds of changes would be opened we would have to add a whole lot of symbols to libc.so. This doesn't come without a cost. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAku+adcACgkQ2ijCOnn/RHQvZACggj8GMPsaR0Q/sVuyjMuGmVZI fMcAmQGquepfyCfImc3ChYoFdJtsIcVs =GG1m -----END PGP SIGNATURE-----