| Message ID | 1c2ee1c40ccde18a008262aeaf23a17da2064eae.1602142232.git.liu.denton@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [RFC] Makefile: create externcheck target | expand |
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 > >
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
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
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.
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))
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(+)