From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7140 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: getenv_r Date: Thu, 5 Mar 2015 01:41:33 +0100 Message-ID: <20150305004133.GI16260@port70.net> References: <20150304230920.GA21838@wilbur.25thandClement.com> 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 1425516111 28266 80.91.229.3 (5 Mar 2015 00:41:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Mar 2015 00:41:51 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7153-gllmg-musl=m.gmane.org@lists.openwall.com Thu Mar 05 01:41:51 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YTJrK-0000uN-FW for gllmg-musl@m.gmane.org; Thu, 05 Mar 2015 01:41:50 +0100 Original-Received: (qmail 21869 invoked by uid 550); 5 Mar 2015 00:41:49 -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 21835 invoked from network); 5 Mar 2015 00:41:45 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20150304230920.GA21838@wilbur.25thandClement.com> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:7140 Archived-At: * William Ahern [2015-03-04 15:09:20 -0800]: > I noticed that getenv is not thread-safe. Would there be any interest in > accepting a patch to implement getenv_r (a NetBSD function) and internal > locking? Other than leaving getenv, setenv, and putenv unsafe in threaded > environments, the only other alternative is the ugliness that glibc, > Solaris, and some others implement, which is basically to leak environ > memory. getenv is thread-safe if the environ is not modified in a multi-threaded application environ modification is unsafe and problematic even if you do the locks: different threads may want different value for an env var and when you read an env var you cannot know if it is up to date when you want to use it. does netbsd use getenv_r somewhere to solve some issue?