Re: [PATCH v5 11/11] run-command: block signals between fork and execve

2017-04-19 Thread Brandon Williams
On 04/19, Eric Wong wrote: > Johannes Sixt wrote: > > Am 19.04.2017 um 01:18 schrieb Brandon Williams: > > >@@ -400,6 +404,53 @@ static char **prep_childenv(const char *const > > >*deltaenv) > > > } > > > #endif > > > > > > > Does this #endif in this hunk context belong to an #ifndef > > GIT_WIN

Re: [PATCH v5 11/11] run-command: block signals between fork and execve

2017-04-19 Thread Eric Wong
Johannes Sixt wrote: > Am 19.04.2017 um 01:18 schrieb Brandon Williams: > >@@ -400,6 +404,53 @@ static char **prep_childenv(const char *const *deltaenv) > > } > > #endif > > > > Does this #endif in this hunk context belong to an #ifndef > GIT_WINDOWS_NATIVE? If so, I wonder why these new function

Re: [PATCH v5 11/11] run-command: block signals between fork and execve

2017-04-18 Thread Johannes Sixt
Am 19.04.2017 um 01:18 schrieb Brandon Williams: @@ -400,6 +404,53 @@ static char **prep_childenv(const char *const *deltaenv) } #endif Does this #endif in this hunk context belong to an #ifndef GIT_WINDOWS_NATIVE? If so, I wonder why these new functions are outside these brackets? An over

[PATCH v5 11/11] run-command: block signals between fork and execve

2017-04-18 Thread Brandon Williams
From: Eric Wong Signal handlers of the parent firing in the forked child may have unintended side effects. Rather than auditing every signal handler we have and will ever have, block signals while forking and restore default signal handlers in the child before execve. Restoring default signal h