Re: [PATCH] compat/mingw.h: drop extern from function declaration

Re: [PATCH] compat/mingw.h: drop extern from function declaration

[Johannes Schindelin]

Hi Denton,

On Wed, 7 Oct 2020, Denton Liu wrote:

> In 554544276a (*.[ch]: remove extern from function declarations using
> spatch, 2019-04-29), `extern` on function declarations were declared to
> be redundant and thus removed from the codebase. An `extern` was
> accidentally reintroduced in 08809c09aa (mingw: add a helper function to
> attach GDB to the current process, 2020-02-13).
>
> Remove this spurious `extern`.

ACK!

Thanks,
Dscho

>
> Signed-off-by: Denton Liu <liu.denton@gmail.com>
> ---
>
> Notes:
>     This patch is based on 554544276a, formerly 'js/mingw-open-in-gdb'.
>
>  compat/mingw.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/compat/mingw.h b/compat/mingw.h
> index 88c07c4520..5c34547539 100644
> --- a/compat/mingw.h
> +++ b/compat/mingw.h
> @@ -599,7 +599,7 @@ int main(int argc, const char **argv);
>   * Call this function to open a new MinTTY (this assumes you are in Git for
>   * Windows' SDK) with a GDB that attaches to the current process right away.
>   */
> -extern void open_in_gdb(void);
> +void open_in_gdb(void);
>
>  /*
>   * Used by Pthread API implementation for Windows
> --
> 2.28.0.942.g77c4c6094c
>
>

[PATCH] compat/mingw.h: drop extern from function declaration

[Denton Liu]

In 554544276a (*.[ch]: remove extern from function declarations using
spatch, 2019-04-29), `extern` on function declarations were declared to
be redundant and thus removed from the codebase. An `extern` was
accidentally reintroduced in 08809c09aa (mingw: add a helper function to
attach GDB to the current process, 2020-02-13).

Remove this spurious `extern`.

Signed-off-by: Denton Liu <liu.denton@gmail.com>
---

Notes:
    This patch is based on 554544276a, formerly 'js/mingw-open-in-gdb'.

 compat/mingw.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/compat/mingw.h b/compat/mingw.h
index 88c07c4520..5c34547539 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -599,7 +599,7 @@ int main(int argc, const char **argv);
  * Call this function to open a new MinTTY (this assumes you are in Git for
  * Windows' SDK) with a GDB that attaches to the current process right away.
  */
-extern void open_in_gdb(void);
+void open_in_gdb(void);
 
 /*
  * Used by Pthread API implementation for Windows
-- 
2.28.0.942.g77c4c6094c

[RFC PATCH] Makefile: create externcheck target

[Denton Liu]

In b199d7147a (*.[ch]: remove extern from function declarations using
sed, 2019-04-29), we used sed to remove extern from function
definitions. In order to help find and remove future instances of this,
teach Makefile the `externcheck` target which runs the sed script
included in that commit on all applicable source files.

Signed-off-by: Denton Liu <liu.denton@gmail.com>
---

Notes:
    I run this target periodically to ensure that no new instances of extern
    function definitions are introduced. Is this something that we want to
    consider adding for real?

 Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Makefile b/Makefile
index 5311b1d2c4..791faa24cf 100644
--- a/Makefile
+++ b/Makefile
@@ -2885,6 +2885,9 @@ COCCI_SOURCES = $(filter-out $(THIRD_PARTY_SOURCES),$(FOUND_C_SOURCES))
 	fi
 coccicheck: $(addsuffix .patch,$(filter-out %.pending.cocci,$(wildcard contrib/coccinelle/*.cocci)))
 
+externcheck: $(filter-out $(THIRD_PARTY_SOURCES),$(filter %.c %.h,$(shell $(FIND_SOURCE_FILES))))
+	sed -i 's/^\(\s*\)extern \([^(]*([^*]\)/\1\2/' $^
+
 # See contrib/coccinelle/README
 coccicheck-pending: $(addsuffix .patch,$(wildcard contrib/coccinelle/*.pending.cocci))
 
-- 
2.29.0.rc0.261.g7178c9af9c

Re: [RFC PATCH] Makefile: create externcheck target

[Johannes Schindelin]

Hi Denton,

On Thu, 8 Oct 2020, Denton Liu wrote:

> In b199d7147a (*.[ch]: remove extern from function declarations using
> sed, 2019-04-29), we used sed to remove extern from function
> definitions. In order to help find and remove future instances of this,
> teach Makefile the `externcheck` target which runs the sed script
> included in that commit on all applicable source files.
>
> Signed-off-by: Denton Liu <liu.denton@gmail.com>
> ---
>
> Notes:
>     I run this target periodically to ensure that no new instances of extern
>     function definitions are introduced. Is this something that we want to
>     consider adding for real?

Sure, and then hook it up in `ci/run-static-analysis.sh`.

But maybe add it _after_ coccicheck-pending, and add it to the `.PHONY`
line that's just outside of this patch's context lines?

Ciao,
Dscho

P.S.: I am not really certain that the `\s` is portable, I do not see any
mention of it in
https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap09.html#tag_09_03
and would therefore expect BSD sed not to handle this correctly. In any
case, the `-i` is _not_ portable, as BSD sed takes a mandatory argument
(see
https://stackoverflow.com/questions/5694228/sed-in-place-flag-that-works-both-on-mac-bsd-and-linux
for more details).

>
>  Makefile | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index 5311b1d2c4..791faa24cf 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2885,6 +2885,9 @@ COCCI_SOURCES = $(filter-out $(THIRD_PARTY_SOURCES),$(FOUND_C_SOURCES))
>  	fi
>  coccicheck: $(addsuffix .patch,$(filter-out %.pending.cocci,$(wildcard contrib/coccinelle/*.cocci)))
>
> +externcheck: $(filter-out $(THIRD_PARTY_SOURCES),$(filter %.c %.h,$(shell $(FIND_SOURCE_FILES))))
> +	sed -i 's/^\(\s*\)extern \([^(]*([^*]\)/\1\2/' $^
> +
>  # See contrib/coccinelle/README
>  coccicheck-pending: $(addsuffix .patch,$(wildcard contrib/coccinelle/*.pending.cocci))
>
> --
> 2.29.0.rc0.261.g7178c9af9c
>
>

Re: [RFC PATCH] Makefile: create externcheck target

[Denton Liu]

Hi Dscho,

On Thu, Oct 08, 2020 at 11:32:03AM +0200, Johannes Schindelin wrote:
> P.S.: I am not really certain that the `\s` is portable, I do not see any
> mention of it in
> https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap09.html#tag_09_03
> and would therefore expect BSD sed not to handle this correctly.

I've run a varation of this on MacOS's sed before and it works.
Unfortunately, I don't have access to a MacOS machine anymore so I can't
100% confirm it.

> In any
> case, the `-i` is _not_ portable, as BSD sed takes a mandatory argument
> (see
> https://stackoverflow.com/questions/5694228/sed-in-place-flag-that-works-both-on-mac-bsd-and-linux
> for more details).

This was the main reason why I sent it out as an RFC (although I forgot
to mention it in the commit message, whoops). Perhaps we could write
this as

	externcheck: $(filter-out $(THIRD_PARTY_SOURCES),$(filter %.c %.h,$(shell $(FIND_SOURCE_FILES))))
		sed -i.bak 's/^\(\s*\)extern \([^(]*([^*]\)/\1\2/' $^
		$(RM) $(addsuffix .bak,$^)

instead? I think that since this is a developer target, we can probably
call this portable enough.

Thanks,
Denton

Re: [RFC PATCH] Makefile: create externcheck target

[Johannes Schindelin]

Hi Denton,

On Thu, 8 Oct 2020, Denton Liu wrote:

> On Thu, Oct 08, 2020 at 11:32:03AM +0200, Johannes Schindelin wrote:
> > P.S.: I am not really certain that the `\s` is portable, I do not see any
> > mention of it in
> > https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap09.html#tag_09_03
> > and would therefore expect BSD sed not to handle this correctly.
>
> I've run a varation of this on MacOS's sed before and it works.
> Unfortunately, I don't have access to a MacOS machine anymore so I can't
> 100% confirm it.
>
> > In any
> > case, the `-i` is _not_ portable, as BSD sed takes a mandatory argument
> > (see
> > https://stackoverflow.com/questions/5694228/sed-in-place-flag-that-works-both-on-mac-bsd-and-linux
> > for more details).
>
> This was the main reason why I sent it out as an RFC (although I forgot
> to mention it in the commit message, whoops). Perhaps we could write
> this as
>
> 	externcheck: $(filter-out $(THIRD_PARTY_SOURCES),$(filter %.c %.h,$(shell $(FIND_SOURCE_FILES))))
> 		sed -i.bak 's/^\(\s*\)extern \([^(]*([^*]\)/\1\2/' $^
> 		$(RM) $(addsuffix .bak,$^)
>
> instead? I think that since this is a developer target, we can probably
> call this portable enough.

Yep, I agree.

Thanks,
Dscho

Re: [RFC PATCH] Makefile: create externcheck target

[Junio C Hamano]

Denton Liu <liu.denton@gmail.com> writes:

> +externcheck: $(filter-out $(THIRD_PARTY_SOURCES),$(filter %.c %.h,$(shell $(FIND_SOURCE_FILES))))
> +	sed -i 's/^\(\s*\)extern \([^(]*([^*]\)/\1\2/' $^

I am not enthused by this particular patch for a few reasons, and I
am moderately negative on the whole idea.

 - We don't aim to support "only GNU and some BSD"; let's not do
   "-i" which as far as I know is used only in config.mak.uname for
   vcxproj target (which is OK as we know that is run only on a very
   narrow target, but probably is a bad idea as it would be another
   source of copy-and-paste for those who do not even think why it
   is acceptable there but not in all other places).

 - Same for \s.  If it is easy enough to write [        ]*, why
   risk breaking for somebody you don't even know?

 - The initial [^*] may be an attempt to avoid triggering on a
   global pointer-to-function, but doesn't it also make the pattern
   fail to trigger on a global function whose return type is a
   pointer-to-function?

 - If this is a "check" target, we shouldn't apply a wholesale
   transformation that is potentially buggy to user's files.  Using
   "grep" to just point out the places where your opinion differ
   from user's (and to fail the "make foocheck" operation) would be
   more appropriate.

Quite honestly, I suspect that the "push" that b199d714 (*.[ch]:
remove extern from function declarations using sed, 2019-04-29)
talks about was misguided in the first place.

Sure, we can write these external function declarations without
'extern' in front, because the language allows it and without
'static' in front, it by default is 'extern'.  It however does
not automatically mean we _should_ drop 'extern'.

Sure, for function decls, it may not make a difference to have or
not have "extern" in front, but for decls of data (including
pointers to functions), it makes a whole lot of difference.  Not
standardising to the rule "our external declarations always are
marked with leading 'extern', regardless of the type of the
identifier being declared" forces us to spend our brain cycles to
think if we should or should not write 'extern' in front.  And is
that a good thing to spend our brain cycles on, or just waste of our
effort?  I am moderately in favor of saying that it is a waste.

In addition, seeing these 'extern ' in header files will train our
eyes to spot the same in the source files more easily.  External
decls in the source (as opposed to inclusion of a header that does
the decls) can happen but they ought to be exceptions and it is good
to make them stand out.