run-command: use void to declare that functions take no parameters
PATCH 1/1 run-command: use void to declare that functions take no parameters
Explicitly declare that git_atexit_dispatch() and git_atexit_clear() take no parameters instead of leaving their parameter list empty and thus unspecified.
--- run-command.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
run-command.c +2 -2
@@ -636,7 +636,7 @@ static struct {static int git_atexit_installed; -static void git_atexit_dispatch () +static void git_atexit_dispatch (void ) {size_t i;
@@ -644,7 +644,7 @@ static void git_atexit_dispatch() git_atexit_hdlrs.handlers[i-1 ](); } -static void git_atexit_clear () +static void git_atexit_clear (void ) {free (git_atexit_hdlrs.handlers);memset (&git_atexit_hdlrs,0 ,sizeof (git_atexit_hdlrs));
Signature · 1 line
2.1.3
Quoted 6 lines · René Scharfe
Explicitly declare that
git_atexit_dispatch()andgit_atexit_clear()take no parameters instead of leaving their parameter list empty and thus unspecified.Signed-off-by Rene Scharfe <[email protected]>---
Thanks.
I was kind of surprised after running a git blame to find that this is a recent thing, and the same patch looked quite substandard with numerious style violations, and I somehow managed to let them slip in X-<. Perhaps I was having a bad day or something...
Quoted 25 lines
run-command.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)run-command.c +2
-2@@ -636,7 +636,7 @@ static struct {static int git_atexit_installed; -static void git_atexit_dispatch () +static void git_atexit_dispatch (void ) {size_t i;@@ -644,7 +644,7 @@ static void git_atexit_dispatch() git_atexit_hdlrs.handlers[i-1 ](); } -static void git_atexit_clear () +static void git_atexit_clear (void ) {free (git_atexit_hdlrs.handlers);memset (&git_atexit_hdlrs,0 ,sizeof (git_atexit_hdlrs));
Quoted 9 lines · Junio C Hamano
Quoted 3 lines
Explicitly declare that
git_atexit_dispatch()andgit_atexit_clear()take no parameters instead of leaving their parameter list empty and thus unspecified.[...]
I was kind of surprised after running a git blame to find that this is a recent thing, and the same patch looked quite substandard with numerious style violations, and I somehow managed to let them slip in X-<. Perhaps I was having a bad day or something...
I had always just assumed that -Wstrict-prototypes was part of -Wall, but it is not (nor even part of -Wextra!). Maybe it is time to add it to your integration-build flags. :)
Looks like we also need this on top of hv/submodule-config (still in pu, so squashing is probably best):
submodule-config.h +1 -1
@@ -24,6 +24,6 @@ const struct submodule *submodule_from_name(const unsigned char *commit_sha1, const char *name);const struct submodule *submodule_from_path (const unsigned char *commit_sha1,const char *path); -void submodule_free (); +void submodule_free (void );#endif /* SUBMODULE_CONFIG_H */
-Peff
Quoted 3 lines · Jeff King
I had always just assumed that -Wstrict-prototypes was part of -Wall, but it is not (nor even part of -Wextra!). Maybe it is time to add it to your integration-build flags. :)
Yup, I had -Wold-style-definition but not -Wstrict-prototypes in the mix. Thanks for spotting.
Quoted 18 lines
Looks like we also need this on top of hv/submodule-config (still in pu, so squashing is probably best):
submodule-config.h +1
-2@@ -24,6 +24,6 @@ const struct submodule *submodule_from_name(const unsigned char *commit_sha1, const char *name);const struct submodule *submodule_from_path (const unsigned char *commit_sha1,const char *path); -void submodule_free (); +void submodule_free (void );#endif /* SUBMODULE_CONFIG_H */ -Peff