threads / patch / 54362

patchcompat/mingw.h: drop extern from function declaration

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

## tl;dr

7 messages between Oct 7, 2020 and Oct 9, 2020. Diffs are folded; open one to read it.

replies: 6people: 3as markdown or json

Denton Liu· Oct 7, 2020, 08:31 UTC · lore

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(-)
Show changes to compat/mingw.h +1 −1
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
Johannes Schindelin· Oct 7, 2020, 06:44 UTC · re: Denton Liu · lore

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

Hi Denton,
On Wed, 7 Oct 2020, Denton Liu wrote:
Show 7 quoted lines
> 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

Show 27 quoted lines
>
> 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
>
>
Denton Liu· Oct 8, 2020, 07:30 UTC · re: Denton Liu · lore

[RFC PATCH] Makefile: create externcheck target

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(+)
Show changes to Makefile +3 −0
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
Johannes Schindelin· Oct 8, 2020, 09:32 UTC · re: Denton Liu · lore

Re: [RFC PATCH] Makefile: create externcheck target

Hi Denton,
On Thu, 8 Oct 2020, Denton Liu wrote:
Show 13 quoted lines
> 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).

Show 22 quoted lines
>
>  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
>
>
Denton Liu· Oct 8, 2020, 09:52 UTC · re: Johannes Schindelin · lore

Re: [RFC PATCH] Makefile: create externcheck target

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.

Show 5 quoted lines
> 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

Johannes Schindelin· Oct 8, 2020, 14:26 UTC · re: Denton Liu · lore

Re: [RFC PATCH] Makefile: create externcheck target

Hi Denton,
On Thu, 8 Oct 2020, Denton Liu wrote:
Show 26 quoted lines
> 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

Junio C Hamano· Oct 9, 2020, 02:45 UTC · re: Denton Liu · lore

Re: [RFC PATCH] Makefile: create externcheck target

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.

← back to recent threads