Date: Mon, 30 Apr 2007 12:56:14 -0400 From: John Baldwin <jhb@freebsd.org> To: Andrey Chernov <ache@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/usr.sbin/sysinstall main.c Message-ID: <200704301256.15557.jhb@freebsd.org> In-Reply-To: <20070430164031.GA82368@nagual.pp.ru> References: <200704301516.l3UFGJbu019162@repoman.freebsd.org> <200704301229.21190.jhb@freebsd.org> <20070430164031.GA82368@nagual.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 30 April 2007 12:40:31 pm Andrey Chernov wrote: > 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. Ok. FWIW, this seems like a ridiculous and gross hack just to provide a backdoor for updating the environment w/o making a fooenv() function call (either putenv, or setenv). -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200704301256.15557.jhb>