Re: [PATCH] Fix a signal handler

3 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH] Fix a signal handler

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:48:19

Markus Elfring [off-list ref] writes:
quoted
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

---
quoted
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 <redacted>
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.
quoted hunk
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.
quoted hunk
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.

Re: [PATCH] Fix a signal handler

From: Markus Elfring <hidden>
Date: 2016-06-15 22:48:20

    Subject: [PATCH] log --early-output: signal handler pedantic fix
I would prefer a correct and portable approach here instead of a "pedantic" one.
  ;-)

I'd phrase the above like this:
It might be that the suggested commit message was too terse.

    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
I would not repeat the specification of undefined behaviour if a reference to a
standard like POSIX will be sufficient.

and that would be sufficiently clear without saying anything else.
It seems that we have got different opinions about the clarity of signal handling.

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".
This data type is actually not used (because an underscore is missing in the
name).   ;-)

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.
Should I really add to the log message that there is another user for it like
the source file "progress.c"?

According to POSIX, "s-e-o" has to be "volatile sig_atomic_t".
How do you think about informations from a discussion on a topic like 'Is
"volatile sig_atomic_t" redundant'?
http://groups.google.de/group/comp.lang.c/browse_frm/thread/da3118a2d2c0737c/718dc093b83e03f8?#718dc093b83e03f8

Also we do not explicitly initialize bss variables to zero or NULL.
If we would like to insist on the implementation of a strictly conforming
program, the source code should be restructured even more.
https://www.securecoding.cert.org/confluence/display/seccode/SIG31-C.+Do+not+access+or+modify+shared+objects+in+signal+handlers

The variable "show_early_output" should be moved to the source file
"builtin-log.c" where it will become "static". Other means would be needed to
transfer corresponding state changes to the function "path_name".

Regards,
Markus

Re: [PATCH] Fix a signal handler

From: Markus Elfring <hidden>
Date: 2016-06-15 22:48:20

Other means would be needed to transfer corresponding state changes to the function "path_name".
I'm sorry for a potential confusion. - The function "limit_list" is the intended
call site so far.

Regards,
Markus
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help