From owner-cvs-all@FreeBSD.ORG Mon Apr 30 16:40:35 2007 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3167716A400; Mon, 30 Apr 2007 16:40:35 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id A082413C4AE; Mon, 30 Apr 2007 16:40:34 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l3UGeXJu082424; Mon, 30 Apr 2007 20:40:33 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l3UGeW6m082422; Mon, 30 Apr 2007 20:40:32 +0400 (MSD) (envelope-from ache) Date: Mon, 30 Apr 2007 20:40:31 +0400 From: Andrey Chernov To: John Baldwin Message-ID: <20070430164031.GA82368@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , John Baldwin , src-committers@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org References: <200704301516.l3UFGJbu019162@repoman.freebsd.org> <200704301229.21190.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200704301229.21190.jhb@freebsd.org> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/usr.sbin/sysinstall main.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2007 16:40:35 -0000 On Mon, Apr 30, 2007 at 12:29:20PM -0400, John Baldwin wrote: > Have you coordinated at all with the guy on current@ who has patches to make > setenv(3) not leak memory as bad? No, I don't touch current allocation scheme at all. It isn't my goal. > Also, given that we malloc a limited space > for the string values, I don't see how you can make it so that one can always > just overwrite the string pointed to by putenv(3)'s return value to change > the value. If we malloc a buffer for length N and the user wants to set the > length to M > N, we pretty much have to malloc a new buffer that will end up > at a different address, so places holding onto the previous value returned > from putenv(3) will stop seeing updates. It isn't the issue. Putenv value supposed to live just up to the next putenv or setenv call, so setenv can legitimately overwrite it. -- http://ache.pp.ru/