Thread (10 messages) flat view 10 messages, 5 authors, 2016-06-15

Re: [PATCH 3/3] Replace setenv(GIT_DIR_ENVIRONMENT, ...) with set_git_dir()

From: Johannes Sixt <hidden>
Date: 2016-06-15 22:43:53

Possibly related (same subject, not in this thread)

Steffen Prohaska schrieb:
On Nov 22, 2007, at 8:52 AM, Junio C Hamano wrote:
quoted
I suspect that if there are even earlier callers than these
early parts in the codepaths (handle_options, enter_repo, and
setup_git_directory_gently), maybe these earlier callers are
doing something wrong.  Logically, if you are somewhere very
early in the codepath that you can still change the value of
GIT_DIR, you shouldn't have assumed the unknown value of GIT_DIR
and cached locations relative to that directory, no?  What are
the problematic callers?  What values do they access and why?

I thought about these questions, too.  But only very briefly.
I did not analyze the code path that lead to calls of getenv().

I'm not sure if it's really necessary.  Calling set_git_dir()
looks more sensible too me than the old code.  I believe using
set_git_dir() is the safer choice, and should not do any harm.
So I stopped analyzing too much, and instead proposed to use
set_git_dir().
Junio's point is this: If we stumble over a dangling pointer that getenv() 
produced, then this has obviously happened before setenv(GIT_DIR), and 
caching that pointer is probably the wrong thing to do anyway (because it 
refers to the wrong GIT_DIR) and needs to be fixed.

So the task is to find those traps. Dmitry obviously stumbled over one case, 
but I haven't ever encountered any problems with the current code. But then 
this might be sheer luck. And I'm not a heavy user of export GIT_DIR=foo, 
either. Do *you* know a problematic case?
Interesting, though, is to find out if we have other potentially
dangerous calls to getenv() that are not removed by this patch.
Side note for other readers: This is a Windows specific problem for the 
moment because its getenv() does not behave well.

-- Hannes
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help