git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] merge-recursive: check GIT_MERGE_VERBOSITY only once

From
MÅMartin Ågren <martin.agren@gmail.com>
Date
Oct 24, 2017, 17:11 UTC
Message-ID
<CAN0heSp7b_6n3y=s4++oWhkPUuM=s9L7LWVx5vn8o=5aH6DKKw@mail.gmail.com>
In-Reply-To
<CAPig+cRTL2amjsgdp1=T3GMZLa=favugOfnQw9XjWzC+U=v5Sw@mail.gmail.com>
On 24 October 2017 at 18:45, Eric Sunshine <sunshine@sunshineco.com> wrote:
Show 7 quoted lines
> On Tue, Oct 24, 2017 at 12:28 PM, Stefan Beller <sbeller@google.com> wrote:
>> On Tue, Oct 24, 2017 at 8:27 AM, Andrey Okoshkin <a.okoshkin@samsung.com> wrote:
>>> Add check of 'GIT_MERGE_VERBOSITY' environment variable only once in
>>> init_merge_options().
>>> Consequential call of getenv() may return NULL pointer and strtol() crashes.
>>> However the stored pointer to the obtained getenv() result may be invalidated
>>> by some other getenv() call from another thread as getenv() is not thread-safe.

I'm having trouble wrapping my head around this. Under which circumstances could the second call in the current code return NULL, but the code after your patch behave in a well-defined (and correct) way?

Show 11 quoted lines
> The distance between getenv() and the point where the value is
> actually used is a big concern due to not knowing what is or might be
> going on in called functions between the two points. According to [1],
> the value returned by getenv() could be invalidated by another call to
> getenv() (or setenv() or unsetenv() or putenv()), and we don't have
> guarantee that we're safe from such invalidation considering that this
> function calls out to others. For instance, after getenv() but before
> the value is used, init_merge_options() calls merge_recursive_config()
> which calls git_config() which calls git_xmerge_config(), and so on.
>
> For this reason, I have difficulty endorsing this change as-is.

Yeah. The call should be immediately before `merge_verbosity` is used. Then, if a compiler wants to move the call, it has to do the work and prove that it's ok.

Previous: Eric SunshineNext: Jeff King
Message 4 of 22 in “merge-recursive: check GIT_MERGE_VERBOSITY only once”
  1. merge-recursive: check GIT_MERGE_VERBOSITY only onceAndrey Okoshkin, Oct 24, 2017
  2. Stefan BellerOct 24, 2017
  3. Eric SunshineOct 24, 2017
  4. Martin ÅgrenOct 24, 2017
  5. Jeff KingOct 24, 2017
  6. Junio C HamanoOct 25, 2017
  7. Eric SunshineOct 25, 2017
  8. Jeff KingOct 25, 2017
  9. merge-recursive: check GIT_MERGE_VERBOSITY only onceAndrey Okoshkin, Oct 25, 2017
  10. Eric SunshineOct 25, 2017
  11. Andrey OkoshkinOct 25, 2017
  12. Andrey OkoshkinOct 25, 2017
  13. Stefan BellerOct 27, 2017
  14. merge-recursive: check GIT_MERGE_VERBOSITY only onceAndrey Okoshkin, Oct 30, 2017
  15. Junio C HamanoOct 31, 2017
  16. Junio C HamanoOct 31, 2017
  17. Andrey OkoshkinOct 31, 2017
  18. Junio C HamanoOct 31, 2017
  19. merge-recursive: check GIT_MERGE_VERBOSITY only onceAndrey Okoshkin, Oct 31, 2017
  20. Andrey OkoshkinOct 25, 2017
  21. Andrey OkoshkinOct 25, 2017
  22. Andrey OkoshkinOct 25, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.