On Sat, Jan 5, 2013 at 1:35 AM, David Michael fedora@gmail.com wrote:
It is possible for this pointer of the GIT_DIR environment variable to
survive unduplicated until further getenv calls are made. The standards
allow for subsequent calls of getenv to overwrite the string located at
its
David Michael fedora@gmail.com writes:
I have encountered an issue with consecutive calls to getenv
overwriting earlier values. Most notably, it prevents a plain git
clone from working.
Long story short: This value of GIT_DIR gets passed around setup.c
until it reaches
On Sat, Jan 5, 2013 at 7:35 AM, David Michael fedora@gmail.com wrote:
-if (gitdirenv)
-return setup_explicit_git_dir(gitdirenv, cwd, len, nongit_ok);
+if (gitdirenv) {
+gitdirenv = xstrdup(gitdirenv);
+ret = setup_explicit_git_dir(gitdirenv, cwd, len,
Junio C Hamano gits...@pobox.com writes:
... So even if the standard allowed the
returned value to be volatile across calls to getenv(3),...
...
In fact,
http://pubs.opengroup.org/onlinepubs/9699919799/functions/getenv.html
says that only ...
Apparently I wasn't even reading what I
Duy Nguyen pclo...@gmail.com writes:
Maybe we could all this into a wrapper? If getenv() here has a
problem, many other places may have the same problem too. This
simplifies the change. But one has to check that getenv() must not be
used in threaded code.
That needs to be done regardless, if
On Sat, Jan 5, 2013 at 11:38 AM, Junio C Hamano gits...@pobox.com wrote:
I personally do not think a wrapper with limited slots is a healthy
direction to go. Most places we use getenv() do not let the return
value live across their scope, and those that do should explicitly
copy the value
Duy Nguyen pclo...@gmail.com writes:
On Sat, Jan 5, 2013 at 11:38 AM, Junio C Hamano gits...@pobox.com wrote:
I personally do not think a wrapper with limited slots is a healthy
direction to go. Most places we use getenv() do not let the return
value live across their scope, and those that
7 matches
Mail list logo
