Re: [PATCH 1/1] mingw: safe-guard a bit more against getenv() problems
- From
Jeff King <peff@peff.net>
- Date
- Feb 21, 2019, 13:52 UTC
- Message-ID
- <20190221135207.GA20899@sigill.intra.peff.net>
- In-Reply-To
- <53e3d159c8c80924188f57c44efd2170612f2ee5.1550243863.git.gitgitgadget@gmail.com>
On Fri, Feb 15, 2019 at 07:17:45AM -0800, Johannes Schindelin via GitGitGadget wrote:
Show 18 quoted lines
> From: Johannes Schindelin <johannes.schindelin@gmx.de> > > Running up to v2.21.0, we fixed two bugs that were made prominent by the > Windows-specific change to retain copies of only the 30 latest getenv() > calls' returned strings, invalidating any copies of previous getenv() > calls' return values. > > While this really shines a light onto bugs of the form where we hold > onto getenv()'s return values without copying them, it is also a real > problem for users. > > And even if Jeff King's patches merged via 773e408881 (Merge branch > 'jk/save-getenv-result', 2019-01-29) provide further work on that front, > we are far from done. Just one example: on Windows, we unset environment > variables when spawning new processes, which potentially invalidates > strings that were previously obtained via getenv(), and therefore we > have to duplicate environment values that are somehow involved in > spawning new processes (e.g. GIT_MAN_VIEWER in show_man_page()).
Belated review, as this is already in master, but: yes, I absolutely support this patch, even on top of my patches. Those were just the cases I found by poking around for a few minutes, and I'm sure there are many more.
-Peff