From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6013 Path: news.gmane.org!not-for-mail From: Alexander Monakov Newsgroups: gmane.linux.lib.musl.general Subject: Re: Retention of LD_LIBRARY_PATH Date: Sun, 31 Aug 2014 17:14:26 +0400 (MSK) Message-ID: References: <20140831124152.GU12888@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: ger.gmane.org 1409490984 8928 80.91.229.3 (31 Aug 2014 13:16:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 31 Aug 2014 13:16:24 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6020-gllmg-musl=m.gmane.org@lists.openwall.com Sun Aug 31 15:16:18 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XO4zQ-000687-BF for gllmg-musl@plane.gmane.org; Sun, 31 Aug 2014 15:16:16 +0200 Original-Received: (qmail 17771 invoked by uid 550); 31 Aug 2014 13:16:15 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 17763 invoked from network); 31 Aug 2014 13:16:15 -0000 In-Reply-To: <20140831124152.GU12888@brightrain.aerifal.cx> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) Xref: news.gmane.org gmane.linux.lib.musl.general:6013 Archived-At: On Sun, 31 Aug 2014, Rich Felker wrote: > On Sun, Aug 31, 2014 at 02:25:18PM +0400, Alexander Monakov wrote: > > The dynamic loader in musl retains a pointer to LD_LIBRARY_PATH from the > > initial environment, which is exposed to the application via 'char **environ'. > > Changes to environ may cause subsequent calls to dlopen to use different > > search paths, but modifications via setenv and putenv do not have such effect. > > "Any application that directly modifies the pointers to which the > environ variable points has undefined behavior." This doesn't seem to cover pointed-to character data (which is 'char' rather than 'const char') without modifying pointers. Apologies for the sloppy wording in my previous email: 'changes to environ' should have been 'changes to LD_LIBRARY_PATH string value (but not location) via environ'. So a conforming application can still notice a difference. I don't feel it's a big problem (non-const char **environ is very iffy to me), but I thought pointing out this discrepancy wouldn't hurt. Thanks for your explanations. Alexander