threads / patch / 34415

patch, 2 partsopen() error checking

Subject: [PATCH 0/2] open() error checking

## tl;dr

16 messages between Jul 12, 2013 and Jul 18, 2013. Diffs are folded; open one to read it.

replies: 15people: 5as markdown or json

Thomas Rast· Jul 12, 2013, 08:58 UTC · lore

#1 is Dale's suggested change. Dale, to include it we'd need your Signed-off-by as per Documentation/SubmittingPatches.

#2 is a similar error-checking fix; I reviewed 'git grep "\bopen\b"' and found one case where the return value was obviously not tested. The corresponding Windows code path has the same problem, but I dare not touch it; perhaps someone from the Windows side can look into it?

I originally had a four-patch series to open 0/1/2 from /dev/null, but then I noticed that this was shot down in 2008:

  http://thread.gmane.org/gmane.comp.version-control.git/93605/focus=93896
Do you want to resurrect this?

The worst part about it is that because we don't have a stderr to rely on, we can't simply die("stop playing mind games").

Dale R. Worley (1):
  git_mkstemps: correctly test return value of open()
Thomas Rast (1):
  run-command: dup_devnull(): guard against syscalls failing
 run-command.c | 5 ++++-
 wrapper.c     | 2 +-
 2 files changed, 5 insertions(+), 2 deletions(-)
-- 
1.8.3.2.998.g1d087bc
Thomas Rast· Jul 12, 2013, 08:58 UTC · re: Thomas Rast · lore

[PATCH 1/2] git_mkstemps: correctly test return value of open()

From: "Dale R. Worley" <worley@alum.mit.edu>

open() returns -1 on failure, and indeed 0 is a possible success value if the user closed stdin in our process. Fix the test.

Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
---
 wrapper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Show changes to wrapper.c +1 −1
diff --git a/wrapper.c b/wrapper.c
index dd7ecbb..6a015de 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -322,7 +322,7 @@ int git_mkstemps_mode(char *pattern, int suffix_len, int mode)
 		template[5] = letters[v % num_letters]; v /= num_letters;
 
 		fd = open(pattern, O_CREAT | O_EXCL | O_RDWR, mode);
-		if (fd > 0)
+		if (fd >= 0)
 			return fd;
 		/*
 		 * Fatal error (EPERM, ENOSPC etc).
-- 
1.8.3.2.998.g1d087bc
Thomas Rast· Jul 16, 2013, 09:37 UTC · re: Thomas Rast · lore

Re: [PATCH 1/2] git_mkstemps: correctly test return value of open()

Thomas Rast <trast@inf.ethz.ch> writes:
Show 6 quoted lines
> From: "Dale R. Worley" <worley@alum.mit.edu>
>
> open() returns -1 on failure, and indeed 0 is a possible success value
> if the user closed stdin in our process.  Fix the test.
>
> Signed-off-by: Thomas Rast <trast@inf.ethz.ch>

I see you have this in 'pu' without Dale's signoff. I'm guessing (IANAL) that it's too small to be copyrighted and anyway there is only way to fix it, but maybe Dale can "sign off" just to be safe, anyway?

Show 16 quoted lines
>  wrapper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/wrapper.c b/wrapper.c
> index dd7ecbb..6a015de 100644
> --- a/wrapper.c
> +++ b/wrapper.c
> @@ -322,7 +322,7 @@ int git_mkstemps_mode(char *pattern, int suffix_len, int mode)
>  		template[5] = letters[v % num_letters]; v /= num_letters;
>  
>  		fd = open(pattern, O_CREAT | O_EXCL | O_RDWR, mode);
> -		if (fd > 0)
> +		if (fd >= 0)
>  			return fd;
>  		/*
>  		 * Fatal error (EPERM, ENOSPC etc).
-- 
Thomas Rast
trast@{inf,student}.ethz.ch
Junio C Hamano· Jul 17, 2013, 19:29 UTC · re: Thomas Rast · lore

Re: [PATCH 1/2] git_mkstemps: correctly test return value of open()

Thomas Rast <trast@inf.ethz.ch> writes:
Show 12 quoted lines
> Thomas Rast <trast@inf.ethz.ch> writes:
>
>> From: "Dale R. Worley" <worley@alum.mit.edu>
>>
>> open() returns -1 on failure, and indeed 0 is a possible success value
>> if the user closed stdin in our process.  Fix the test.
>>
>> Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
>
> I see you have this in 'pu' without Dale's signoff.  I'm guessing
> (IANAL) that it's too small to be copyrighted and anyway there is only
> way to fix it, but maybe Dale can "sign off" just to be safe, anyway?
Yup, that is a good idea.  Thanks.
Show 17 quoted lines
>
>>  wrapper.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/wrapper.c b/wrapper.c
>> index dd7ecbb..6a015de 100644
>> --- a/wrapper.c
>> +++ b/wrapper.c
>> @@ -322,7 +322,7 @@ int git_mkstemps_mode(char *pattern, int suffix_len, int mode)
>>  		template[5] = letters[v % num_letters]; v /= num_letters;
>>  
>>  		fd = open(pattern, O_CREAT | O_EXCL | O_RDWR, mode);
>> -		if (fd > 0)
>> +		if (fd >= 0)
>>  			return fd;
>>  		/*
>>  		 * Fatal error (EPERM, ENOSPC etc).
Drew Northup· Jul 18, 2013, 12:32 UTC · re: Junio C Hamano · lore

Re: [PATCH 1/2] git_mkstemps: correctly test return value of open()

I presume that I should apply this change to my porting of git_mkstemps_mode() to tig. If there are no complaints about this for a couple of days I will do so.

REF: $gmane/229961
On 07/17/2013 03:29 PM, Junio C Hamano wrote:
Show 8 quoted lines
> Thomas Rast<trast@inf.ethz.ch>  writes:
>> Thomas Rast<trast@inf.ethz.ch>  writes:
>>> From: "Dale R. Worley"<worley@alum.mit.edu>
>>>
>>> open() returns -1 on failure, and indeed 0 is a possible success value
>>> if the user closed stdin in our process.  Fix the test.
>>>
>>> Signed-off-by: Thomas Rast<trast@inf.ethz.ch>
Show 16 quoted lines
>>>   wrapper.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/wrapper.c b/wrapper.c
>>> index dd7ecbb..6a015de 100644
>>> --- a/wrapper.c
>>> +++ b/wrapper.c
>>> @@ -322,7 +322,7 @@ int git_mkstemps_mode(char *pattern, int suffix_len, int mode)
>>>   		template[5] = letters[v % num_letters]; v /= num_letters;
>>>
>>>   		fd = open(pattern, O_CREAT | O_EXCL | O_RDWR, mode);
>>> -		if (fd>  0)
>>> +		if (fd>= 0)
>>>   			return fd;
>>>   		/*
>>>   		 * Fatal error (EPERM, ENOSPC etc).

-- -Drew Northup -------------------------------------------------------------- "As opposed to vegetable or mineral error?" -John Pescatore, SANS NewsBites Vol. 12 Num. 59

Junio C Hamano· Jul 18, 2013, 17:46 UTC · re: Drew Northup · lore

Re: [PATCH 1/2] git_mkstemps: correctly test return value of open()

Drew Northup <n1xim.email@gmail.com> writes:
> I presume that I should apply this change to my porting of
> git_mkstemps_mode() to tig. If there are no complaints about this for
> a couple of days I will do so.
Hmph, Thomas and I were actually asking you to give us
	Signed-off-by: Drew Northup <n1xim.email@gmail.com>

for the patch in question. If tig has the same issue, applying that same patch there may make sense, but that is an independent issue.

Thanks.
Show 36 quoted lines
>
> REF: $gmane/229961
>
> On 07/17/2013 03:29 PM, Junio C Hamano wrote:
>> Thomas Rast<trast@inf.ethz.ch>  writes:
>>> Thomas Rast<trast@inf.ethz.ch>  writes:
>>>> From: "Dale R. Worley"<worley@alum.mit.edu>
>>>>
>>>> open() returns -1 on failure, and indeed 0 is a possible success value
>>>> if the user closed stdin in our process.  Fix the test.
>>>>
>>>> Signed-off-by: Thomas Rast<trast@inf.ethz.ch>
>
>>>>   wrapper.c | 2 +-
>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/wrapper.c b/wrapper.c
>>>> index dd7ecbb..6a015de 100644
>>>> --- a/wrapper.c
>>>> +++ b/wrapper.c
>>>> @@ -322,7 +322,7 @@ int git_mkstemps_mode(char *pattern, int suffix_len, int mode)
>>>>   		template[5] = letters[v % num_letters]; v /= num_letters;
>>>>
>>>>   		fd = open(pattern, O_CREAT | O_EXCL | O_RDWR, mode);
>>>> -		if (fd>  0)
>>>> +		if (fd>= 0)
>>>>   			return fd;
>>>>   		/*
>>>>   		 * Fatal error (EPERM, ENOSPC etc).
>
>
> --
> -Drew Northup
> --------------------------------------------------------------
> "As opposed to vegetable or mineral error?"
> -John Pescatore, SANS NewsBites Vol. 12 Num. 59
Junio C Hamano· Jul 18, 2013, 17:47 UTC · re: Junio C Hamano · lore

Re: [PATCH 1/2] git_mkstemps: correctly test return value of open()

Junio C Hamano <gitster@pobox.com> writes:
Show 9 quoted lines
> Drew Northup <n1xim.email@gmail.com> writes:
>
>> I presume that I should apply this change to my porting of
>> git_mkstemps_mode() to tig. If there are no complaints about this for
>> a couple of days I will do so.
>
> Hmph, Thomas and I were actually asking you to give us
>
> 	Signed-off-by: Drew Northup <n1xim.email@gmail.com>

Gaahhh, I need a bit more caffeine. Somehow I mixed up Dale and Drew.

Sorry for the noise.  Please ignore.
Show 41 quoted lines
> for the patch in question.  If tig has the same issue, applying that
> same patch there may make sense, but that is an independent issue.
>
> Thanks.
>
>>
>> REF: $gmane/229961
>>
>> On 07/17/2013 03:29 PM, Junio C Hamano wrote:
>>> Thomas Rast<trast@inf.ethz.ch>  writes:
>>>> Thomas Rast<trast@inf.ethz.ch>  writes:
>>>>> From: "Dale R. Worley"<worley@alum.mit.edu>
>>>>>
>>>>> open() returns -1 on failure, and indeed 0 is a possible success value
>>>>> if the user closed stdin in our process.  Fix the test.
>>>>>
>>>>> Signed-off-by: Thomas Rast<trast@inf.ethz.ch>
>>
>>>>>   wrapper.c | 2 +-
>>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/wrapper.c b/wrapper.c
>>>>> index dd7ecbb..6a015de 100644
>>>>> --- a/wrapper.c
>>>>> +++ b/wrapper.c
>>>>> @@ -322,7 +322,7 @@ int git_mkstemps_mode(char *pattern, int suffix_len, int mode)
>>>>>   		template[5] = letters[v % num_letters]; v /= num_letters;
>>>>>
>>>>>   		fd = open(pattern, O_CREAT | O_EXCL | O_RDWR, mode);
>>>>> -		if (fd>  0)
>>>>> +		if (fd>= 0)
>>>>>   			return fd;
>>>>>   		/*
>>>>>   		 * Fatal error (EPERM, ENOSPC etc).
>>
>>
>> --
>> -Drew Northup
>> --------------------------------------------------------------
>> "As opposed to vegetable or mineral error?"
>> -John Pescatore, SANS NewsBites Vol. 12 Num. 59
Dale R. Worley· Jul 18, 2013, 20:32 UTC · re: Junio C Hamano · lore

Re: [PATCH 1/2] git_mkstemps: correctly test return value of open()

I've been looking into writing a proper test for this patch. My first attempt tests the symptom that was seen initially, that "git commit" fails if fd 0 is closed.

One problem is how to arrange for fd 0 to be closed. I could use the bash redirection "<&-", but I think you want to be more portable than that. This version uses execvp() inside a small C program, and execvp() is a Posix function.

I've tested that this test does what it should: If you remove the fix, "fd >= 0", the test fails. If you then remove "test-close-fd-0" from before "git init" in the test, the test is nullified and succeeds again.

Here is the diff.  What do people think of it?
Show changes to 4 files +23 −1

Makefile, t/t0070-fundamental.sh, test-close-fd-0.c, wrapper.c

diff --git a/Makefile b/Makefile
index 0600eb4..6b410f5 100644
--- a/Makefile
+++ b/Makefile
@@ -557,6 +557,7 @@ X =
 PROGRAMS += $(patsubst %.o,git-%$X,$(PROGRAM_OBJS))
 
 TEST_PROGRAMS_NEED_X += test-chmtime
+TEST_PROGRAMS_NEED_X += test-close-fd-0
 TEST_PROGRAMS_NEED_X += test-ctype
 TEST_PROGRAMS_NEED_X += test-date
 TEST_PROGRAMS_NEED_X += test-delta
diff --git a/t/t0070-fundamental.sh b/t/t0070-fundamental.sh
index 986b2a8..6a31103 100755
--- a/t/t0070-fundamental.sh
+++ b/t/t0070-fundamental.sh
@@ -25,6 +25,13 @@ test_expect_success POSIXPERM,SANITY 'mktemp to unwritable directory prints file
 	grep "cannotwrite/test" err
 '
 
+test_expect_success 'git_mkstemps_mode does not fail if fd 0 is not open' '
+	git init &&
+	echo Test. >test-file &&
+	git add test-file &&
+	test-close-fd-0 git commit -m Message.
+'
+
 test_expect_success 'check for a bug in the regex routines' '
 	# if this test fails, re-build git with NO_REGEX=1
 	test-regex
diff --git a/test-close-fd-0.c b/test-close-fd-0.c
new file mode 100644
index 0000000..3745c34
--- /dev/null
+++ b/test-close-fd-0.c
@@ -0,0 +1,14 @@
+#include <unistd.h>
+
+/* Close file descriptor 0 (which is standard-input), then execute the
+ * remainder of the command line as a command. */
+
+int main(int argc, char **argv)
+{
+	/* Close fd 0. */
+	close(0);
+	/* Execute the requested command. */
+	execvp(argv[1], &argv[1]);
+	/* If execve() failed, return an error. */
+	return 1;
+}
diff --git a/wrapper.c b/wrapper.c
index dd7ecbb..6a015de 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -322,7 +322,7 @@ int git_mkstemps_mode(char *pattern, int suffix_len, int mode)
 		template[5] = letters[v % num_letters]; v /= num_letters;
 
 		fd = open(pattern, O_CREAT | O_EXCL | O_RDWR, mode);
-		if (fd > 0)
+		if (fd >= 0)
 			return fd;
 		/*
 		 * Fatal error (EPERM, ENOSPC etc).

Dale
Eric Sunshine· Jul 18, 2013, 20:49 UTC · re: Dale R. Worley · lore

Re: [PATCH 1/2] git_mkstemps: correctly test return value of open()

On Thu, Jul 18, 2013 at 4:32 PM, Dale R. Worley <worley@alum.mit.edu> wrote:
Show 8 quoted lines
> I've been looking into writing a proper test for this patch.  My first
> attempt tests the symptom that was seen initially, that "git commit"
> fails if fd 0 is closed.
>
> One problem is how to arrange for fd 0 to be closed.  I could use the
> bash redirection "<&-", but I think you want to be more portable than
> that.  This version uses execvp() inside a small C program, and
> execvp() is a Posix function.
"<&-" is POSIX.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_05
Show 6 quoted lines
> I've tested that this test does what it should:  If you remove the
> fix, "fd >= 0", the test fails.  If you then remove "test-close-fd-0"
> from before "git init" in the test, the test is nullified and succeeds
> again.
>
> Here is the diff.  What do people think of it?
Junio C Hamano· Jul 18, 2013, 20:54 UTC · re: Dale R. Worley · lore

Re: [PATCH 1/2] git_mkstemps: correctly test return value of open()

On Thu, Jul 18, 2013 at 1:32 PM, Dale R. Worley <worley@alum.mit.edu> wrote:
Show 7 quoted lines
> I've been looking into writing a proper test for this patch.  My first
> attempt tests the symptom that was seen initially, that "git commit"
> fails if fd 0 is closed.
>
> One problem is how to arrange for fd 0 to be closed.  I could use the
> bash redirection "<&-", but I think you want to be more portable than
> that.
That's just a plain-vanilla part of POSIX shell behaviour, no?
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_05
Dale R. Worley· Jul 18, 2013, 22:46 UTC · re: Junio C Hamano · lore

Re: [PATCH 1/2] git_mkstemps: correctly test return value of open()

Show 5 quoted lines
> From: Junio C Hamano <gitster@pobox.com>
> 
> That's just a plain-vanilla part of POSIX shell behaviour, no?
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_05

"Close standard input" is so weird I never thought it was Posix. In that case, we can eliminate the C helper program:

Show changes to 2 files +8 −1

t/t0070-fundamental.sh, wrapper.c

diff --git a/t/t0070-fundamental.sh b/t/t0070-fundamental.sh
index 986b2a8..d427f3a 100755
--- a/t/t0070-fundamental.sh
+++ b/t/t0070-fundamental.sh
@@ -25,6 +25,13 @@ test_expect_success POSIXPERM,SANITY 'mktemp to unwritable directory prints file
 	grep "cannotwrite/test" err
 '
 
+test_expect_success 'git_mkstemps_mode does not fail if fd 0 is not open' '
+	git init &&
+	echo Test. >test-file &&
+	git add test-file &&
+	git commit -m Message. <&-
+'
+
 test_expect_success 'check for a bug in the regex routines' '
 	# if this test fails, re-build git with NO_REGEX=1
 	test-regex
diff --git a/wrapper.c b/wrapper.c
index dd7ecbb..6a015de 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -322,7 +322,7 @@ int git_mkstemps_mode(char *pattern, int suffix_len, int mode)
 		template[5] = letters[v % num_letters]; v /= num_letters;
 
 		fd = open(pattern, O_CREAT | O_EXCL | O_RDWR, mode);
-		if (fd > 0)
+		if (fd >= 0)
 			return fd;
 		/*
 		 * Fatal error (EPERM, ENOSPC etc).

Is this a sensible place to put this test?

Dale
Junio C Hamano· Jul 18, 2013, 23:23 UTC · re: Dale R. Worley · lore

Re: [PATCH 1/2] git_mkstemps: correctly test return value of open()

worley@alum.mit.edu (Dale R. Worley) writes:
Show 24 quoted lines
>> From: Junio C Hamano <gitster@pobox.com>
>> 
>> That's just a plain-vanilla part of POSIX shell behaviour, no?
>> 
>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_05
>
> "Close standard input" is so weird I never thought it was Posix.  In
> that case, we can eliminate the C helper program:
>
> diff --git a/t/t0070-fundamental.sh b/t/t0070-fundamental.sh
> index 986b2a8..d427f3a 100755
> --- a/t/t0070-fundamental.sh
> +++ b/t/t0070-fundamental.sh
> @@ -25,6 +25,13 @@ test_expect_success POSIXPERM,SANITY 'mktemp to unwritable directory prints file
>  	grep "cannotwrite/test" err
>  '
>  
> +test_expect_success 'git_mkstemps_mode does not fail if fd 0 is not open' '
> +	git init &&
> +	echo Test. >test-file &&
> +	git add test-file &&
> +	git commit -m Message. <&-
> +'
> +
Yup.  I wonder how it would fail without the fix, though ;-)
Show 20 quoted lines
>  test_expect_success 'check for a bug in the regex routines' '
>  	# if this test fails, re-build git with NO_REGEX=1
>  	test-regex
> diff --git a/wrapper.c b/wrapper.c
> index dd7ecbb..6a015de 100644
> --- a/wrapper.c
> +++ b/wrapper.c
> @@ -322,7 +322,7 @@ int git_mkstemps_mode(char *pattern, int suffix_len, int mode)
>  		template[5] = letters[v % num_letters]; v /= num_letters;
>  
>  		fd = open(pattern, O_CREAT | O_EXCL | O_RDWR, mode);
> -		if (fd > 0)
> +		if (fd >= 0)
>  			return fd;
>  		/*
>  		 * Fatal error (EPERM, ENOSPC etc).
>
> Is this a sensible place to put this test?
>
> Dale
Dale R. Worley· Jul 18, 2013, 23:29 UTC · re: Junio C Hamano · lore

Re: [PATCH 1/2] git_mkstemps: correctly test return value of open()

> From: Junio C Hamano <gitster@pobox.com>
Show 9 quoted lines
> > +test_expect_success 'git_mkstemps_mode does not fail if fd 0 is not open' '
> > +	git init &&
> > +	echo Test. >test-file &&
> > +	git add test-file &&
> > +	git commit -m Message. <&-
> > +'
> > +
> 
> Yup.  I wonder how it would fail without the fix, though ;-)

Eh, what? You could run it and see. The test script system will just say "not ok" for this test. If you execute those commands from a shell, you see:

 $ git init
Initialized empty Git repository in /common/not-replicated/worley/temp/1/.git/
 $ echo Test. >test-file
 $ git add test-file
 $ git commit -m Message. <&-
error: unable to create temporary sha1 filename : No such file or directory
error: Error building trees
 $ 
Dale
Thomas Rast· Jul 12, 2013, 08:58 UTC · re: Thomas Rast · lore

[PATCH 2/2] run-command: dup_devnull(): guard against syscalls failing

dup_devnull() did not check the return values of open() and dup2(). Fix this omission.

Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
---
 run-command.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
Show changes to run-command.c +4 −1
diff --git a/run-command.c b/run-command.c
index aece872..1b7f88e 100644
--- a/run-command.c
+++ b/run-command.c
@@ -76,7 +76,10 @@ static inline void close_pair(int fd[2])
 static inline void dup_devnull(int to)
 {
 	int fd = open("/dev/null", O_RDWR);
-	dup2(fd, to);
+	if (fd < 0)
+		die_errno(_("open /dev/null failed"));
+	if (dup2(fd, to) < 0)
+		die_errno(_("dup2(%d,%d) failed"), fd, to);
 	close(fd);
 }
 #endif
-- 
1.8.3.2.998.g1d087bc
Junio C Hamano· Jul 12, 2013, 17:29 UTC · re: Thomas Rast · lore

Re: [PATCH 0/2] open() error checking

Thomas Rast <trast@inf.ethz.ch> writes:
Show 12 quoted lines
> #1 is Dale's suggested change.  Dale, to include it we'd need your
> Signed-off-by as per Documentation/SubmittingPatches.
>
> #2 is a similar error-checking fix; I reviewed 'git grep "\bopen\b"'
> and found one case where the return value was obviously not tested.
> The corresponding Windows code path has the same problem, but I dare
> not touch it; perhaps someone from the Windows side can look into it?
>
> I originally had a four-patch series to open 0/1/2 from /dev/null, but
> then I noticed that this was shot down in 2008:
>
>   http://thread.gmane.org/gmane.comp.version-control.git/93605/focus=93896

The way I recall the thread was not "shot down" but more like "fizzled out without seeing a clear consensus". As a normal POSIX program, we do rely on fd#2 connected to an error stream, and I do agree with the general sentiment of that old thread that it is very wrong for warning() or die() to write to a pipe or file descriptor we opened for some other purpose, corrupting the destination.

I briefly wondered if we can do the sanity check lazily (e.g. upon first warning() see of fd#2 is open and otherwise die silently), but we may open a fd (e.g. to create a new loose object) that may happen to grab fd#2 and then it is too late for us to do anything about it, so...

> Do you want to resurrect this?
>
> The worst part about it is that because we don't have a stderr to rely
> on, we can't simply die("stop playing mind games").
Right.
Thomas Rast· Jul 16, 2013, 09:25 UTC · re: Junio C Hamano · lore

Re: [PATCH 0/2] open() error checking

Junio C Hamano <gitster@pobox.com> writes:
Show 19 quoted lines
> Thomas Rast <trast@inf.ethz.ch> writes:
>
>> I originally had a four-patch series to open 0/1/2 from /dev/null, but
>> then I noticed that this was shot down in 2008:
>>
>>   http://thread.gmane.org/gmane.comp.version-control.git/93605/focus=93896
>
> The way I recall the thread was not "shot down" but more like
> "fizzled out without seeing a clear consensus".  As a normal POSIX
> program, we do rely on fd#2 connected to an error stream, and I do
> agree with the general sentiment of that old thread that it is very
> wrong for warning() or die() to write to a pipe or file descriptor
> we opened for some other purpose, corrupting the destination.
>
> I briefly wondered if we can do the sanity check lazily (e.g. upon
> first warning() see of fd#2 is open and otherwise die silently), but
> we may open a fd (e.g. to create a new loose object) that may happen
> to grab fd#2 and then it is too late for us to do anything about it,
> so...

I think we'd have to do it on startup. Since we do many things already, a few extra dup calls should hardly matter.

I'll send the patches in reply in a minute, I had them lying around already. But if you (again) decide that it's not worth it, I don't care too deeply.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

← back to recent threads