git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* [PATCH] run-command.c: fix build warnings on Ubuntu
@ 2010-01-29 22:38 Michael Wookey
  2010-01-30 16:43 ` Markus Heidelberg
  2011-03-16  3:51 ` [PATCH] run-command: prettify -D_FORTIFY_SOURCE workaround Jonathan Nieder
  0 siblings, 2 replies; 8+ messages in thread
From: Michael Wookey @ 2010-01-29 22:38 UTC (permalink / raw
  To: Git Mailing List

Building git on Ubuntu 9.10 warns that the return value of write(2)
isn't checked. These warnings were introduced in commits:

  2b541bf8 ("start_command: detect execvp failures early")
  a5487ddf ("start_command: report child process setup errors to the
parent's stderr")

GCC details:

  $ gcc --version
  gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1

Silence the warnings by reading (but not making use of) the return value
of write(2).

Signed-off-by: Michael Wookey <michaelwookey@gmail.com>
---
Although this will fix the build warnings, I am unsure if there is a
better way to achieve the same result. Using "(void)write(...)" still
gives warnings and I am unaware of any annotations that will silence
gcc.

 run-command.c |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/run-command.c b/run-command.c
index 2feb493..3206d61 100644
--- a/run-command.c
+++ b/run-command.c
@@ -67,19 +67,21 @@ static int child_notifier = -1;

 static void notify_parent(void)
 {
-	write(child_notifier, "", 1);
+	ssize_t unused;
+	unused = write(child_notifier, "", 1);
 }

 static NORETURN void die_child(const char *err, va_list params)
 {
 	char msg[4096];
+	ssize_t unused;
 	int len = vsnprintf(msg, sizeof(msg), err, params);
 	if (len > sizeof(msg))
 		len = sizeof(msg);

-	write(child_err, "fatal: ", 7);
-	write(child_err, msg, len);
-	write(child_err, "\n", 1);
+	unused = write(child_err, "fatal: ", 7);
+	unused = write(child_err, msg, len);
+	unused = write(child_err, "\n", 1);
 	exit(128);
 }

-- 
1.7.0.rc0.48.gdace5

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH] run-command.c: fix build warnings on Ubuntu
  2010-01-29 22:38 [PATCH] run-command.c: fix build warnings on Ubuntu Michael Wookey
@ 2010-01-30 16:43 ` Markus Heidelberg
  2011-03-16  3:51 ` [PATCH] run-command: prettify -D_FORTIFY_SOURCE workaround Jonathan Nieder
  1 sibling, 0 replies; 8+ messages in thread
From: Markus Heidelberg @ 2010-01-30 16:43 UTC (permalink / raw
  To: Michael Wookey; +Cc: Git Mailing List

Michael Wookey, 2010-01-29:
> Building git on Ubuntu 9.10 warns that the return value of write(2)
> isn't checked.
> 
> GCC details:
> 
>   $ gcc --version
>   gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1
> 
> Silence the warnings by reading (but not making use of) the return value
> of write(2).

Since a few weeks I get several warnings about fwrite(), currently 28
times this:
warning: ignoring return value of ‘fwrite’, declared with attribute warn_unused_result

gcc (Gentoo 4.3.4 p1.0, pie-10.1.5) 4.3.4

Not sure if it should be muted, that are really many places.

Markus

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH] run-command: prettify -D_FORTIFY_SOURCE workaround
  2010-01-29 22:38 [PATCH] run-command.c: fix build warnings on Ubuntu Michael Wookey
  2010-01-30 16:43 ` Markus Heidelberg
@ 2011-03-16  3:51 ` Jonathan Nieder
  2011-03-16  5:37   ` Junio C Hamano
  1 sibling, 1 reply; 8+ messages in thread
From: Jonathan Nieder @ 2011-03-16  3:51 UTC (permalink / raw
  To: git; +Cc: Michael Wookey, Markus Heidelberg, Junio C Hamano

Current gcc + glibc with -D_FORTIFY_SOURCE try very aggressively to
protect against a programming style which uses write(...) without
checking the return value for errors.  Even the usual hint of casting
to (void) does not suppress the warning.

Sometimes when there is an output error, especially right before exit,
there really is nothing to be done.  The obvious solution, adopted in
v1.7.0.3~20^2 (run-command.c: fix build warnings on Ubuntu,
2010-01-30), is to save the return value to a dummy variable:

	ssize_t dummy;
	dummy = write(...);

But that (1) is ugly and (2) triggers -Wunused-but-set-variable
warnings with gcc-4.6 -Wall, so we are not much better off than when
we started.

Instead, use an "if" statement with an empty body to make the intent
clear.

	if (write(...))
		; /* yes, yes, there was an error. */

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Hi,

Michael Wookey wrote:

> Although this will fix the build warnings, I am unsure if there is a
> better way to achieve the same result. Using "(void)write(...)" still
> gives warnings and I am unaware of any annotations that will silence
> gcc.

It's been a long time (and meanwhile the patch has been working;
thanks!).  How about something like this?

 run-command.c |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/run-command.c b/run-command.c
index 3206d61..5b68907 100644
--- a/run-command.c
+++ b/run-command.c
@@ -67,21 +67,21 @@ static int child_notifier = -1;
 
 static void notify_parent(void)
 {
-	ssize_t unused;
-	unused = write(child_notifier, "", 1);
+	if (write(child_notifier, "", 1))
+		; /* ok. */
 }
 
 static NORETURN void die_child(const char *err, va_list params)
 {
 	char msg[4096];
-	ssize_t unused;
 	int len = vsnprintf(msg, sizeof(msg), err, params);
 	if (len > sizeof(msg))
 		len = sizeof(msg);
 
-	unused = write(child_err, "fatal: ", 7);
-	unused = write(child_err, msg, len);
-	unused = write(child_err, "\n", 1);
+	if (write(child_err, "fatal: ", 7) ||
+	    write(child_err, msg, len) ||
+	    write(child_err, "\n", 1))
+		; /* ok. */
 	exit(128);
 }
 
-- 
1.7.4.1

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH] run-command: prettify -D_FORTIFY_SOURCE workaround
  2011-03-16  3:51 ` [PATCH] run-command: prettify -D_FORTIFY_SOURCE workaround Jonathan Nieder
@ 2011-03-16  5:37   ` Junio C Hamano
  2011-03-16  7:32     ` [PATCH v2] " Jonathan Nieder
  2011-03-16  9:17     ` [PATCH] " Johannes Sixt
  0 siblings, 2 replies; 8+ messages in thread
From: Junio C Hamano @ 2011-03-16  5:37 UTC (permalink / raw
  To: Jonathan Nieder; +Cc: git, Michael Wookey, Markus Heidelberg, Junio C Hamano

Jonathan Nieder <jrnieder@gmail.com> writes:

> Instead, use an "if" statement with an empty body to make the intent
> clear.
>
> 	if (write(...))
> 		; /* yes, yes, there was an error. */

Yuck --- and that is not meant against your workaround, but against the
compiler bogosity.  The above is reasonable (for some definition of the
word) and the comment makes the yuckiness tolerable by being somewhat
amusing.

But your comment in the actual patch is not amusing at all.

It certainly is _not_ "ok" to see errors from write(2); we are _ignoring_
the error because at that point in the codepath there isn't any better
alternative.  The unusual "if ()" whose condition is solely for its side
effect, with an empty body, is a strong enough sign to any reader that
there is something fishy going on, and it would be helpful to the reader
to hint _why_ such an unusual construct is there.  It would be much better
for the longer term maintainability to say at least "gcc" in the comment,
i.e.

	if (write(...))
        	; /* we know we are ignoring the error, mr gcc! */

or something.

Thanks for another amusing patch.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH v2] run-command: prettify -D_FORTIFY_SOURCE workaround
  2011-03-16  5:37   ` Junio C Hamano
@ 2011-03-16  7:32     ` Jonathan Nieder
  2011-03-17 22:34       ` Junio C Hamano
  2011-03-16  9:17     ` [PATCH] " Johannes Sixt
  1 sibling, 1 reply; 8+ messages in thread
From: Jonathan Nieder @ 2011-03-16  7:32 UTC (permalink / raw
  To: Junio C Hamano; +Cc: git, Michael Wookey, Markus Heidelberg

Current gcc + glibc with -D_FORTIFY_SOURCE try very aggressively to
protect against a programming style which uses write(...) without
checking the return value for errors.  Even the usual hint of casting
to (void) does not suppress the warning.

Sometimes when there is an output error, especially right before exit,
there really is nothing to be done.  The obvious solution, adopted in
v1.7.0.3~20^2 (run-command.c: fix build warnings on Ubuntu,
2010-01-30), is to save the return value to a dummy variable:

	ssize_t dummy;
	dummy = write(...);

But that (1) is ugly and (2) triggers -Wunused-but-set-variable
warnings with gcc-4.6 -Wall, so we are not much better off than when
we started.

Instead, use an "if" statement with an empty body to make the intent
clear.

	if (write(...))
		; /* yes, yes, there was an error. */

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Improved-by: Junio C Hamano <gitster@pobox.com>
---
Junio C Hamano wrote:

>               The unusual "if ()" whose condition is solely for its side
> effect, with an empty body, is a strong enough sign to any reader that
> there is something fishy going on, and it would be helpful to the reader
> to hint _why_ such an unusual construct is there.  It would be much better
> for the longer term maintainability to say at least "gcc" in the comment,
> i.e.
> 
> 	if (write(...))
>         	; /* we know we are ignoring the error, mr gcc! */

Very true.  Some comments to that effect below.

 run-command.c |   17 +++++++++++------
 1 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/run-command.c b/run-command.c
index 3206d61..ecd9d1c 100644
--- a/run-command.c
+++ b/run-command.c
@@ -67,21 +67,26 @@ static int child_notifier = -1;
 
 static void notify_parent(void)
 {
-	ssize_t unused;
-	unused = write(child_notifier, "", 1);
+	/*
+	 * execvp failed.  If possible, we'd like to let start_command
+	 * know, so failures like ENOENT can be handled right away; but
+	 * otherwise, finish_command will still report the error.
+	 */
+	if (write(child_notifier, "", 1))
+		; /* yes, dear gcc -D_FORTIFY_SOURCE, there was an error. */
 }
 
 static NORETURN void die_child(const char *err, va_list params)
 {
 	char msg[4096];
-	ssize_t unused;
 	int len = vsnprintf(msg, sizeof(msg), err, params);
 	if (len > sizeof(msg))
 		len = sizeof(msg);
 
-	unused = write(child_err, "fatal: ", 7);
-	unused = write(child_err, msg, len);
-	unused = write(child_err, "\n", 1);
+	if (write(child_err, "fatal: ", 7) ||
+	    write(child_err, msg, len) ||
+	    write(child_err, "\n", 1))
+		; /* yes, gcc -D_FORTIFY_SOURCE, we know there was an error. */
 	exit(128);
 }
 
-- 
1.7.4.1

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH] run-command: prettify -D_FORTIFY_SOURCE workaround
  2011-03-16  5:37   ` Junio C Hamano
  2011-03-16  7:32     ` [PATCH v2] " Jonathan Nieder
@ 2011-03-16  9:17     ` Johannes Sixt
  2011-03-16  9:25       ` Jonathan Nieder
  1 sibling, 1 reply; 8+ messages in thread
From: Johannes Sixt @ 2011-03-16  9:17 UTC (permalink / raw
  To: Junio C Hamano; +Cc: Jonathan Nieder, git, Michael Wookey, Markus Heidelberg

Am 3/16/2011 6:37, schrieb Junio C Hamano:
> It certainly is _not_ "ok" to see errors from write(2); we are _ignoring_
> the error because at that point in the codepath there isn't any better
> alternative.  The unusual "if ()" whose condition is solely for its side
> effect, with an empty body, is a strong enough sign to any reader that
> there is something fishy going on, and it would be helpful to the reader
> to hint _why_ such an unusual construct is there.  It would be much better
> for the longer term maintainability to say at least "gcc" in the comment,
> i.e.
> 
> 	if (write(...))
>         	; /* we know we are ignoring the error, mr gcc! */

And what about compilers that warn:

	';' : empty controlled statement found; is this the intent?

That's from MSVC. Perhaps:

	if (write(...))
		(void)0; /* we know we are ignoring the error, mr gcc! */

-- Hannes

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] run-command: prettify -D_FORTIFY_SOURCE workaround
  2011-03-16  9:17     ` [PATCH] " Johannes Sixt
@ 2011-03-16  9:25       ` Jonathan Nieder
  0 siblings, 0 replies; 8+ messages in thread
From: Jonathan Nieder @ 2011-03-16  9:25 UTC (permalink / raw
  To: Johannes Sixt; +Cc: Junio C Hamano, git, Michael Wookey, Markus Heidelberg

Johannes Sixt wrote:

> And what about compilers that warn:
> 
> 	';' : empty controlled statement found; is this the intent?
>
> That's from MSVC. Perhaps:
>
> 	if (write(...))
> 		(void)0; /* we know we are ignoring the error, mr gcc! */

Mm, thanks for pointing it out.

Your suggestion is part of a bigger change that imho should go in a
separate patch:

	$ git grep -F -e '	; /*' origin/master | wc -l
	65

I would prefer to see such a patch do

	if (write(...)) {
		/* ... explanation goes here ... */
	}

or something like

	#define do_nothing() do { /* nothing */ } while (0)

	if (write(...))
		do_nothing();	/* ... explanation ... */

but that is a small detail.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v2] run-command: prettify -D_FORTIFY_SOURCE workaround
  2011-03-16  7:32     ` [PATCH v2] " Jonathan Nieder
@ 2011-03-17 22:34       ` Junio C Hamano
  0 siblings, 0 replies; 8+ messages in thread
From: Junio C Hamano @ 2011-03-17 22:34 UTC (permalink / raw
  To: Jonathan Nieder; +Cc: git, Michael Wookey, Markus Heidelberg

Jonathan Nieder <jrnieder@gmail.com> writes:

>  static NORETURN void die_child(const char *err, va_list params)
>  {
> ...
> -	unused = write(child_err, "fatal: ", 7);
> -	unused = write(child_err, msg, len);
> -	unused = write(child_err, "\n", 1);
> +	if (write(child_err, "fatal: ", 7) ||
> +	    write(child_err, msg, len) ||
> +	    write(child_err, "\n", 1))
> +		; /* yes, gcc -D_FORTIFY_SOURCE, we know there was an error. */

Strictly speaking, this changes behaviour by stopping at the first failure
from write(2), but I don't think we care.

Thanks.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2011-03-17 22:34 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-29 22:38 [PATCH] run-command.c: fix build warnings on Ubuntu Michael Wookey
2010-01-30 16:43 ` Markus Heidelberg
2011-03-16  3:51 ` [PATCH] run-command: prettify -D_FORTIFY_SOURCE workaround Jonathan Nieder
2011-03-16  5:37   ` Junio C Hamano
2011-03-16  7:32     ` [PATCH v2] " Jonathan Nieder
2011-03-17 22:34       ` Junio C Hamano
2011-03-16  9:17     ` [PATCH] " Johannes Sixt
2011-03-16  9:25       ` Jonathan Nieder

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).