git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Markus Elfring <Markus.Elfring@web.de>
Cc: Jeff King <peff@peff.net>, git@vger.kernel.org
Subject: Re: [PATCH] Fix a signal handler
Date: Mon, 22 Feb 2010 10:31:57 -0800	[thread overview]
Message-ID: <7v1vgdgm02.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <4B82744B.4060805@web.de> (Markus Elfring's message of "Mon\, 22 Feb 2010 13\:10\:51 +0100")

Markus Elfring <Markus.Elfring@web.de> writes:

>> Of are you asking me if I'd apply your patch if you send a polished update,
>> and asking me to decide it before seeing the patch?
>
> Would you like to pick this source code adjustment up?
>
> Regards,
> Markus
>
> ---
>>From e138904a08ceaf469fa2f4d0ec87b5891be14760 Mon Sep 17 00:00:00 2001

It would be preferred to remove everything above this line when you send
patches.

> From: Markus Elfring <Markus.Elfring@web.de>
> Date: Mon, 22 Feb 2010 11:53:35 +0100
> Subject: [PATCH] Fix a signal handler

Please be a bit more careful when coming up with what Subject: says; it
will be the only piece of information to tell the reader of output from
"git shortlog" what the commit made from this patch is about.  E.g.

    Subject: [PATCH] log --early-output: signal handler pedantic fix

> A global flag can only be set by a signal handler in a portable way
> if it has got the data type "sig_atomic_t". The previously used assignment
> of a function pointer in the function "early_output" was moved to another
> variable in the function "setup_early_output".

The first sentence gives the basis of your argument (so that people can
decide to agree or disagree with you).  Then you describe why you think
the code you are changing is wrong --- oops, that part is missing --- and
what you did based on the above two observations --- oops, that part is
missing, too --- and then any additional info.

I'd phrase the above like this:

    The behavior is undefined if the signal handler refers to any object
    other than errno with static storage duration other than by assigning
    a value to a static storage duration variable of type "volatile
    sig_atomic_t", but the existing code updates a variable that holds a
    pointer to a function (i.e. not a sigatomic_t variable).

    Change it to only set a flag, and adjust the callsite that calls the
    early-output function to check it.

and that would be sufficiently clear without saying anything else.

> diff --git a/builtin-log.c b/builtin-log.c
> index e0d5caa..beccf7f 100644
> --- a/builtin-log.c
> +++ b/builtin-log.c
> @@ -170,20 +170,14 @@ static void log_show_early(struct rev_info *revs, struct commit_list *list)
>  
>  static void early_output(int signal)
>  {
> -	show_early_output = log_show_early;
> +	show_early_output = 1;
>  }
>  
>  static void setup_early_output(struct rev_info *rev)
>  {
>  	struct sigaction sa;
>  
> -	/*
> -	 * Set up the signal handler, minimally intrusively:
> -	 * we only set a single volatile integer word (not
> -	 * using sigatomic_t - trying to avoid unnecessary
> -	 * system dependencies and headers), and using
> -	 * SA_RESTART.
> -	 */
> +	early_output_function = &log_show_early;

Your proposed log message also needs to make a good counter-argument why
the above "we purposely avoid using sigatomic_t --- it is not worth the
hassle of having to deal with systems that lack this type in practice" is
worried too much, and it now is sensible to assume that everybody has
sigatomic_t these days to allow us do "the right thing".  It can be just
as simple as 'Output from "git grep sigatomic_t" indicates that we are
already using it.' but you need to say something, as this comment you are
removing makes it clear that it was not a bug by mistake or ignorance, but
instead was a deliberate choice.

> diff --git a/revision.c b/revision.c
> index 3ba6d99..62402fb 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -13,7 +13,8 @@
>  #include "decorate.h"
>  #include "log-tree.h"
>  
> -volatile show_early_output_fn_t show_early_output;
> +sig_atomic_t show_early_output = 0;
> +show_early_output_fn_t early_output_function = NULL;

According to POSIX, "s-e-o" has to be "volatile sig_atomic_t".  Also we do
not explicitly initialize bss variables to zero or NULL.

Thanks.

  reply	other threads:[~2010-02-22 18:32 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-02 16:14 Fix signal handler Markus Elfring
2010-02-02 20:58 ` Jeff King
2010-02-02 21:44   ` Markus Elfring
2010-02-02 22:32     ` Jeff King
2010-02-03 10:20       ` Markus Elfring
2010-02-03 10:29         ` Jeff King
2010-02-03 11:55           ` Markus Elfring
2010-02-03 13:12             ` Thomas Rast
2010-02-03 15:46               ` Markus Elfring
2010-02-03 15:52                 ` Shawn O. Pearce
2010-02-03 15:53                 ` Andreas Ericsson
2010-02-03 16:24                   ` Markus Elfring
2010-02-04  7:23                     ` Andreas Ericsson
2010-02-03 15:17             ` Jeff King
2010-02-03 16:04               ` Markus Elfring
2010-02-03 16:26                 ` Bill Lear
2010-02-09 18:01   ` Markus Elfring
2010-02-09 23:49     ` Daniel Barkalow
2010-02-10 17:08     ` [PATCH] " Markus Elfring
2010-02-10 17:14       ` Shawn O. Pearce
2010-02-10 17:35         ` Jeff King
2010-02-10 17:33       ` Jeff King
2010-02-13 13:30         ` Markus Elfring
2010-02-14  6:47           ` Jeff King
2010-02-14 10:19             ` Junio C Hamano
2010-02-18 16:31               ` Markus Elfring
2010-02-18 20:06                 ` Junio C Hamano
2010-02-19 11:05                   ` Markus Elfring
2010-02-22 12:10                   ` [PATCH] Fix a " Markus Elfring
2010-02-22 18:31                     ` Junio C Hamano [this message]
2010-02-23  8:55                       ` Markus Elfring
2010-02-23  9:10                         ` Markus Elfring
2010-02-23 21:48                         ` Junio C Hamano
2010-02-24 10:38                           ` Markus Elfring
2010-02-24 10:51                             ` Andreas Ericsson
2010-02-24 11:08                           ` Markus Elfring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7v1vgdgm02.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Markus.Elfring@web.de \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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 NNTP newsgroup(s).