From owner-freebsd-current Fri Aug 7 12:33:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA04119 for freebsd-current-outgoing; Fri, 7 Aug 1998 12:33:23 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA04109 for ; Fri, 7 Aug 1998 12:33:20 -0700 (PDT) (envelope-from dag-erli@ifi.uio.no) Received: from hrotti.ifi.uio.no (2602@hrotti.ifi.uio.no [129.240.64.15]) by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with ESMTP id VAA17410; Fri, 7 Aug 1998 21:32:33 +0200 (MET DST) Received: (from dag-erli@localhost) by hrotti.ifi.uio.no ; Fri, 7 Aug 1998 21:32:32 +0200 (MET DST) Mime-Version: 1.0 To: Archie Cobbs Cc: wollman@khavrinen.lcs.mit.edu (Garrett Wollman), freebsd-current@FreeBSD.ORG, bde@zeta.org.au, dg@root.com Subject: Re: memory leaks in libc References: <199808071737.KAA29957@bubba.whistle.com> Organization: University of Oslo, Department of Informatics X-url: http://www.stud.ifi.uio.no/~dag-erli/ X-other-addresses: 'finger dag-erli@ifi.uio.no' for a list X-disclaimer-1: The views expressed in this article are mine alone, and do X-disclaimer-2: not necessarily coincide with those of any organisation or X-disclaimer-3: company with which am or have been affiliated. X-Stop-Spam: http://www.cauce.org/ From: dag-erli@ifi.uio.no (Dag-Erling Coidan =?iso-8859-1?Q?Sm=F8rgrav?= ) Date: 07 Aug 1998 21:32:31 +0200 In-Reply-To: Archie Cobbs's message of "Fri, 7 Aug 1998 10:37:26 -0700 (PDT)" Message-ID: Lines: 38 X-Mailer: Gnus v5.5/Emacs 19.34 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id MAA04113 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Archie Cobbs writes: > Garrett Wollman writes: > > No, you've missed the point entirely. *Any program which does enough > > playing around with the environment to be harmed by this memory leak > > is using a totally inappropriate interface.* > I disagree with that statement! And I base my disagreement not on > conjecture but on experience. There is only one situation in which you need to change the environment: fork-and-exec, in which case it is trivial to construct a fresh environment for your child process in a safe manner. If you're not fork-and-execing, use program variables instead (which you initialize with getenv()). If you're writing a shell and need to keep track of lots of environment variables and pass them to your children, you're in both situations at once; use a hash table for quick lookup (you'll need it for variable substitution in command lines) and pass execve() a list of pointers to the contents of your hash table. > How can it possibly do this? The only way to get strftime() to > acknowledge a change in timezone is to do something like this: > > unsetenv("TZ"); > tzset(); > setenv("TZ", "/etc/localtime", 1); > tzset(); Then strftime() should be taken out and shot. Arguably, so should setenv(), but fixing setenv() will only hide the symptoms of bad programming practice. That said, I don't really see any reason *not* to commit your setenv() replacement, if it works properly. It's just that there aren't really any arguments *for* the commit, either. DES -- Dag-Erling Smørgrav - dag-erli@ifi.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message