{"thread":{"id":"53297","subject":"[PATCH 1/4] C: s/0/NULL/ for pointer type","startedAt":"2020-04-23T13:48:08Z","lastAt":"2020-05-14T21:37:16Z","messageCount":51,"participants":["Đoàn Trần Công Danh","Ramsay Jones","Danh Doan","Junio C Hamano","Jeff King","Johannes Schindelin","Luc Van Oostenryck"],"isPatch":true,"patchVersion":1,"patchTotal":4},"messages":[{"id":"396003","messageId":"c4fac2ae9d10bc426cb26e4a102b808549696763.1587648870.git.congdanhqx@gmail.com","threadId":"53297","inReplyTo":"cover.1587648870.git.congdanhqx@gmail.com","subject":"[PATCH 1/4] C: s/0/NULL/ for pointer type","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-04-23T13:47:53Z","receivedAt":"2020-04-23T13:48:08Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"Fix warning from  `make sparse`.\n\nSigned-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>\n---\n add-interactive.c                   | 2 +-\n builtin/fmt-merge-msg.c             | 2 +-\n log-tree.c                          | 4 ++--\n range-diff.c                        | 2 +-\n t/helper/test-parse-pathspec-file.c | 6 +++---\n 5 files changed, 8 insertions(+), 8 deletions(-)\n\ndiff --git a/add-interactive.c b/add-interactive.c\nindex 29cd2fe020..b8983838b9 100644\n--- a/add-interactive.c\n+++ b/add-interactive.c\n@@ -526,7 +526,7 @@ static int get_modified_files(struct repository *r,\n \n \tfor (i = 0; i < 2; i++) {\n \t\tstruct rev_info rev;\n-\t\tstruct setup_revision_opt opt = { 0 };\n+\t\tstruct setup_revision_opt opt = { NULL };\n \n \t\tif (filter == INDEX_ONLY)\n \t\t\ts.mode = (i == 0) ? FROM_INDEX : FROM_WORKTREE;\ndiff --git a/builtin/fmt-merge-msg.c b/builtin/fmt-merge-msg.c\nindex 172dfbd852..f4376bccef 100644\n--- a/builtin/fmt-merge-msg.c\n+++ b/builtin/fmt-merge-msg.c\n@@ -494,7 +494,7 @@ static void fmt_merge_msg_sigs(struct strbuf *out)\n \t\tenum object_type type;\n \t\tunsigned long size, len;\n \t\tchar *buf = read_object_file(oid, &type, &size);\n-\t\tstruct signature_check sigc = { 0 };\n+\t\tstruct signature_check sigc = { NULL };\n \t\tstruct strbuf sig = STRBUF_INIT;\n \n \t\tif (!buf || type != OBJ_TAG)\ndiff --git a/log-tree.c b/log-tree.c\nindex 0064788b25..ca721150d4 100644\n--- a/log-tree.c\n+++ b/log-tree.c\n@@ -449,7 +449,7 @@ static void show_signature(struct rev_info *opt, struct commit *commit)\n {\n \tstruct strbuf payload = STRBUF_INIT;\n \tstruct strbuf signature = STRBUF_INIT;\n-\tstruct signature_check sigc = { 0 };\n+\tstruct signature_check sigc = { NULL };\n \tint status;\n \n \tif (parse_signed_commit(commit, &payload, &signature) <= 0)\n@@ -496,7 +496,7 @@ static int show_one_mergetag(struct commit *commit,\n \tstruct object_id oid;\n \tstruct tag *tag;\n \tstruct strbuf verify_message;\n-\tstruct signature_check sigc = { 0 };\n+\tstruct signature_check sigc = { NULL };\n \tint status, nth;\n \tsize_t payload_size;\n \ndiff --git a/range-diff.c b/range-diff.c\nindex f745567cf6..71dcd947c5 100644\n--- a/range-diff.c\n+++ b/range-diff.c\n@@ -107,7 +107,7 @@ static int read_patches(const char *range, struct string_list *list,\n \t\t}\n \n \t\tif (starts_with(line, \"diff --git\")) {\n-\t\t\tstruct patch patch = { 0 };\n+\t\t\tstruct patch patch = { NULL };\n \t\t\tstruct strbuf root = STRBUF_INIT;\n \t\t\tint linenr = 0;\n \ndiff --git a/t/helper/test-parse-pathspec-file.c b/t/helper/test-parse-pathspec-file.c\nindex 02f4ccfd2a..b3e08cef4b 100644\n--- a/t/helper/test-parse-pathspec-file.c\n+++ b/t/helper/test-parse-pathspec-file.c\n@@ -6,7 +6,7 @@\n int cmd__parse_pathspec_file(int argc, const char **argv)\n {\n \tstruct pathspec pathspec;\n-\tconst char *pathspec_from_file = 0;\n+\tconst char *pathspec_from_file = NULL;\n \tint pathspec_file_nul = 0, i;\n \n \tstatic const char *const usage[] = {\n@@ -20,9 +20,9 @@ int cmd__parse_pathspec_file(int argc, const char **argv)\n \t\tOPT_END()\n \t};\n \n-\tparse_options(argc, argv, 0, options, usage, 0);\n+\tparse_options(argc, argv, NULL, options, usage, 0);\n \n-\tparse_pathspec_file(&pathspec, 0, 0, 0, pathspec_from_file,\n+\tparse_pathspec_file(&pathspec, 0, 0, NULL, pathspec_from_file,\n \t\t\t    pathspec_file_nul);\n \n \tfor (i = 0; i < pathspec.nr; i++)\n-- \n2.26.2.384.g435bf60bd5\n\n"},{"id":"396004","messageId":"cover.1587648870.git.congdanhqx@gmail.com","threadId":"53297","inReplyTo":null,"subject":"[PATCH 0/4] fix make sparse warning","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-04-23T13:47:52Z","receivedAt":"2020-04-23T13:48:09Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"It's happened that I tried to run make check on project that support autoconf.\nGit's Makefile told me to run `make sparse` instead.\n\nI /think/ if we have a rule in Makefile, we should adhere to it.\nI also fix another change in ds/blame-on-bloom, which I think it's worth to\nfix, see: <20200423133937.GA1984@danh.dev>\n\nThis series is developed from latest master.\n\nIt's conflicted when merge down next and pu.\n\nFor next, please ignore the conflict with fmt-merge-msg.c and\napply [5/4] instead.\n\nFor pu, reftable.c has too much warnings, I'm too lazy to look into it.\n\nĐoàn Trần Công Danh (4):\n  C: s/0/NULL/ for pointer type\n  compat/regex: silence `make sparse` warning\n  graph.c: limit linkage of internal variable\n  progress.c: silence cgcc suggestion about internal linkage\n\n add-interactive.c                   | 2 +-\n builtin/fmt-merge-msg.c             | 2 +-\n compat/regex/regex.c                | 1 +\n compat/regex/regex_internal.c       | 2 +-\n compat/regex/regex_internal.h       | 5 ++---\n graph.c                             | 2 +-\n log-tree.c                          | 4 ++--\n progress.c                          | 2 ++\n range-diff.c                        | 2 +-\n t/helper/test-parse-pathspec-file.c | 6 +++---\n 10 files changed, 15 insertions(+), 13 deletions(-)\n\n-- \n2.26.2.384.g435bf60bd5\n\n"},{"id":"396005","messageId":"25f595f56f7f895ab31bf7269aabad9142c0590c.1587648870.git.congdanhqx@gmail.com","threadId":"53297","inReplyTo":"cover.1587648870.git.congdanhqx@gmail.com","subject":"[PATCH 2/4] compat/regex: silence `make sparse` warning","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-04-23T13:47:54Z","receivedAt":"2020-04-23T13:48:10Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"* alloca: somewhere later in the code, we indirectly include alloca.h\nwhich will define alloca again, include it prior to define alloca in\norder to not define it against.\n\n* Copy all attributes from the header to source file, and move the\n  attributes prior to function name. cgcc is very picky on the position\n  of attribute.\n\nSigned-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>\n---\n compat/regex/regex.c          | 1 +\n compat/regex/regex_internal.c | 2 +-\n compat/regex/regex_internal.h | 5 ++---\n 3 files changed, 4 insertions(+), 4 deletions(-)\n\ndiff --git a/compat/regex/regex.c b/compat/regex/regex.c\nindex f3e03a9eab..4bef75a716 100644\n--- a/compat/regex/regex.c\n+++ b/compat/regex/regex.c\n@@ -62,6 +62,7 @@\n #include <stdint.h>\n \n #ifdef GAWK\n+#include <alloca.h>\n #undef alloca\n #define alloca alloca_is_bad_you_should_never_use_it\n #endif\ndiff --git a/compat/regex/regex_internal.c b/compat/regex/regex_internal.c\nindex ec51cf3446..58504f795b 100644\n--- a/compat/regex/regex_internal.c\n+++ b/compat/regex/regex_internal.c\n@@ -921,7 +921,7 @@ re_string_destruct (re_string_t *pstr)\n /* Return the context at IDX in INPUT.  */\n \n static unsigned int\n-internal_function\n+internal_function __attribute ((pure))\n re_string_context_at (const re_string_t *input, int idx, int eflags)\n {\n   int c;\ndiff --git a/compat/regex/regex_internal.h b/compat/regex/regex_internal.h\nindex 3ee8aae59d..c61a1e4971 100644\n--- a/compat/regex/regex_internal.h\n+++ b/compat/regex/regex_internal.h\n@@ -430,9 +430,8 @@ static reg_errcode_t build_wcs_upper_buffer (re_string_t *pstr)\n # endif /* RE_ENABLE_I18N */\n static void build_upper_buffer (re_string_t *pstr) internal_function;\n static void re_string_translate_buffer (re_string_t *pstr) internal_function;\n-static unsigned int re_string_context_at (const re_string_t *input, int idx,\n-\t\t\t\t\t  int eflags)\n-     internal_function __attribute ((pure));\n+static internal_function __attribute ((pure))\n+unsigned int re_string_context_at (const re_string_t *input, int idx, int eflags);\n #endif\n #define re_string_peek_byte(pstr, offset) \\\n   ((pstr)->mbs[(pstr)->cur_idx + offset])\n-- \n2.26.2.384.g435bf60bd5\n\n"},{"id":"396006","messageId":"5bd7b929107c277e10a697bc874b702b85691558.1587648870.git.congdanhqx@gmail.com","threadId":"53297","inReplyTo":"cover.1587648870.git.congdanhqx@gmail.com","subject":"[PATCH 3/4] graph.c: limit linkage of internal variable","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-04-23T13:47:55Z","receivedAt":"2020-04-23T13:48:13Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>\n---\n graph.c | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/graph.c b/graph.c\nindex 4fb25ad464..4cd9915075 100644\n--- a/graph.c\n+++ b/graph.c\n@@ -1055,7 +1055,7 @@ static void graph_output_commit_line(struct git_graph *graph, struct graph_line\n \t\tgraph_update_state(graph, GRAPH_COLLAPSING);\n }\n \n-const char merge_chars[] = {'/', '|', '\\\\'};\n+static const char merge_chars[] = {'/', '|', '\\\\'};\n \n static void graph_output_post_merge_line(struct git_graph *graph, struct graph_line *line)\n {\n-- \n2.26.2.384.g435bf60bd5\n\n"},{"id":"396007","messageId":"dddf2d402702a616e04e7e446e31e0c6697d8c49.1587648870.git.congdanhqx@gmail.com","threadId":"53297","inReplyTo":"cover.1587648870.git.congdanhqx@gmail.com","subject":"[PATCH 4/4] progress.c: silence cgcc suggestion about internal linkage","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-04-23T13:47:56Z","receivedAt":"2020-04-23T13:48:15Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>\n---\n progress.c | 2 ++\n 1 file changed, 2 insertions(+)\n\ndiff --git a/progress.c b/progress.c\nindex 19805ac646..fb53a2ec0c 100644\n--- a/progress.c\n+++ b/progress.c\n@@ -50,7 +50,9 @@ static volatile sig_atomic_t progress_update;\n  * These are only intended for testing the progress output, i.e. exclusively\n  * for 'test-tool progress'.\n  */\n+extern int progress_testing; /* to silence sparse: internal linkage */\n int progress_testing;\n+extern uint64_t progress_test_ns; /* to silence sparse: internal linkage */\n uint64_t progress_test_ns = 0;\n void progress_test_force_update(void); /* To silence -Wmissing-prototypes */\n void progress_test_force_update(void)\n-- \n2.26.2.384.g435bf60bd5\n\n"},{"id":"396008","messageId":"20200423134811.8634-1-congdanhqx@gmail.com","threadId":"53297","inReplyTo":"cover.1587648870.git.congdanhqx@gmail.com","subject":"[PATCH 5/4] fmt-merge-msg.c: fix `make sparse` on next","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-04-23T13:47:57Z","receivedAt":"2020-04-23T13:48:15Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"Probably, un-necessary, since this is merged down to master.\n\nSigned-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>\n---\n fmt-merge-msg.c | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/fmt-merge-msg.c b/fmt-merge-msg.c\nindex 08022ed2e4..72d32bd73b 100644\n--- a/fmt-merge-msg.c\n+++ b/fmt-merge-msg.c\n@@ -484,7 +484,7 @@ static void fmt_merge_msg_sigs(struct strbuf *out)\n \t\tenum object_type type;\n \t\tunsigned long size, len;\n \t\tchar *buf = read_object_file(oid, &type, &size);\n-\t\tstruct signature_check sigc = { 0 };\n+\t\tstruct signature_check sigc = { NULL };\n \t\tstruct strbuf sig = STRBUF_INIT;\n \n \t\tif (!buf || type != OBJ_TAG)\n-- \n2.26.2.384.g435bf60bd5\n\n"},{"id":"396062","messageId":"86ef24e2-3ab6-5e9c-900b-0eb4dbc1bb04@ramsayjones.plus.com","threadId":"53297","inReplyTo":"cover.1587648870.git.congdanhqx@gmail.com","subject":"Re: [PATCH 0/4] fix make sparse warning","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2020-04-23T23:10:25Z","receivedAt":"2020-04-23T23:18:10Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 23/04/2020 14:47, Đoàn Trần Công Danh wrote:\n> It's happened that I tried to run make check on project that support autoconf.\n\nI try to ignore autoconf as much as possible, so I don't know why people\nwho use it regularly seem to expect a 'make check' target (is that anything\nto do with ./config.status --recheck?).\n\n> Git's Makefile told me to run `make sparse` instead.\n\nIn which case, you must have had sparse installed, otherwise you would\nhave been directed to 'make test'. [See commit 912f9980d2 (\"Makefile: help\npeople who run 'make check' by mistake\", 2008-11-11)]\n\nThe 'check' target was introduced in commit 44c9e8594e (\"Fix up header file\ndependencies and add sparse checking rules\", 2005-07-03). As you can see,\nthat target has nothing to do with autoconf/configure.\n\nExactly a year later, support for autoconf tools was added in commit\n556677144b (\"autoconf: Use autoconf to write installation directories to config.mak.autogen\", 2006-07-03). This provides an 'alternative' to just\nusing the Makefile (which is the _primary_ method used to build git).\n\nI suspect that the majority of git developers don't use the autoconf\ntools (I have no numbers, just gut feeling).\n\nI added the 'sparse' target in commit 0bcd9ae85d (\"sparse: Fix errors due to missing target-specific variables\", 2011-04-21). After nine years, we could\nperhaps just drop the 'check' target altogether? dunno.\n\n> I /think/ if we have a rule in Makefile, we should adhere to it.\n\nHmm, do you mean that 'make check' should be _reserved_ for autoconf use?\n[fun fact: the test target in the sparse Makefile is 'check' :-D ]\n\n> I also fix another change in ds/blame-on-bloom, which I think it's worth to\n> fix, see: <20200423133937.GA1984@danh.dev>\n\nYes, looks good.\n\n> This series is developed from latest master.\n\nI have some comments on the patches (I'm running out of time here,\nso I may not get to them till tomorrow).\n\n> It's conflicted when merge down next and pu.\n> \n> For next, please ignore the conflict with fmt-merge-msg.c and\n> apply [5/4] instead.\n> \n> For pu, reftable.c has too much warnings, I'm too lazy to look into it.\n\nFor those interested, the 'too much warnings' on the 'pu' branch looks\nlike (for pu@faf094bf11):\n\n  $ make sparse >psp-out 2>&1\n  $ diff nsp-out psp-out\n  154a155\n  >     SP refs/reftable-backend.c\n  406a408\n  >     SP t/helper/test-proc-receive.c\n  447a450,511\n  >     SP reftable/basics.c\n  > reftable/basics.c:157:6: warning: symbol 'reftable_malloc_ptr' was not declared. Should it be static?\n  > reftable/basics.c:158:6: warning: symbol 'reftable_realloc_ptr' was not declared. Should it be static?\n  > reftable/basics.c:159:6: warning: symbol 'reftable_free_ptr' was not declared. Should it be static?\n  >     SP reftable/block.c\n  >     SP reftable/bytes.c\n  >     SP reftable/file.c\n  > reftable/file.c:57:37: warning: symbol 'file_vtable' was not declared. Should it be static?\n  >     SP reftable/iter.c\n  > reftable/iter.c:32:33: warning: symbol 'empty_vtable' was not declared. Should it be static?\n  > reftable/iter.c:61:31: warning: Using plain integer as NULL pointer\n  > reftable/iter.c:69:31: warning: Using plain integer as NULL pointer\n  > reftable/iter.c:96:57: warning: Using plain integer as NULL pointer\n  > reftable/iter.c:124:33: warning: symbol 'filtering_ref_iterator_vtable' was not declared. Should it be static?\n  > reftable/iter.c:224:33: warning: symbol 'indexed_table_ref_iter_vtable' was not declared. Should it be static?\n  >     SP reftable/merged.c\n  > reftable/merged.c:141:33: warning: symbol 'merged_iter_vtable' was not declared. Should it be static?\n  > reftable/merged.c:283:31: warning: Using plain integer as NULL pointer\n  > reftable/merged.c:296:31: warning: Using plain integer as NULL pointer\n  >     SP reftable/pq.c\n  >     SP reftable/reader.c\n  > reftable/reader.c:180:42: warning: Using plain integer as NULL pointer\n  > reftable/reader.c:181:42: warning: Using plain integer as NULL pointer\n  > reftable/reader.c:284:41: warning: Using plain integer as NULL pointer\n  > reftable/reader.c:360:44: warning: Using plain integer as NULL pointer\n  > reftable/reader.c:396:33: warning: symbol 'table_iter_vtable' was not declared. Should it be static?\n  > reftable/reader.c:450:36: warning: Using plain integer as NULL pointer\n  > reftable/reader.c:498:42: warning: Using plain integer as NULL pointer\n  > reftable/reader.c:500:44: warning: Using plain integer as NULL pointer\n  > reftable/reader.c:501:42: warning: Using plain integer as NULL pointer\n  > reftable/reader.c:502:36: warning: Using plain integer as NULL pointer\n  > reftable/reader.c:565:34: warning: Using plain integer as NULL pointer\n  > reftable/reader.c:610:31: warning: Using plain integer as NULL pointer\n  > reftable/reader.c:623:31: warning: Using plain integer as NULL pointer\n  > reftable/reader.c:669:36: warning: Using plain integer as NULL pointer\n  > reftable/reader.c:670:42: warning: Using plain integer as NULL pointer\n  > reftable/reader.c:671:35: warning: Using plain integer as NULL pointer\n  > reftable/reader.c:672:35: warning: Using plain integer as NULL pointer\n  >     SP reftable/record.c\n  > reftable/record.c:556:22: warning: symbol 'obj_record_vtable' was not declared. Should it be static?\n  > reftable/record.c:839:22: warning: symbol 'reftable_log_record_vtable' was not declared. Should it be static?\n  > reftable/record.c:961:22: warning: symbol 'index_record_vtable' was not declared. Should it be static?\n  >     SP reftable/slice.c\n  > reftable/slice.c:180:37: warning: symbol 'slice_vtable' was not declared. Should it be static?\n  > reftable/slice.c:200:37: warning: symbol 'malloc_vtable' was not declared. Should it be static?\n  > reftable/slice.c:204:30: warning: symbol 'malloc_block_source_instance' was not declared. Should it be static?\n  >     SP reftable/stack.c\n  > reftable/stack.c:157:62: warning: Using plain integer as NULL pointer\n  > reftable/stack.c:667:41: warning: Using plain integer as NULL pointer\n  > reftable/stack.c:668:44: warning: Using plain integer as NULL pointer\n  > reftable/stack.c:669:44: warning: Using plain integer as NULL pointer\n  > reftable/stack.c:1085:41: warning: Using plain integer as NULL pointer\n  > reftable/stack.c:1111:41: warning: Using plain integer as NULL pointer\n  >     SP reftable/tree.c\n  >     SP reftable/writer.c\n  > reftable/writer.c:231:31: warning: Using plain integer as NULL pointer\n  > reftable/writer.c:299:39: warning: Using plain integer as NULL pointer\n  > reftable/writer.c:347:47: warning: Using plain integer as NULL pointer\n  > reftable/writer.c:426:31: warning: Using plain integer as NULL pointer\n  > reftable/writer.c:468:45: warning: Using plain integer as NULL pointer\n  > reftable/writer.c:584:11: warning: symbol 'debug' was not declared. Should it be static?\n  >     SP reftable/zlib-compat.c\n\nAlso, my static-check perl script says the following symbols are not\nused outside the file which defines them (so they could be marked static):\n\n  $ ./static-check.pl >psc\n  $ diff nsc psc\n  71a72,136\n  > reftable/basics.o\t- reftable_free_ptr\n  > reftable/basics.o\t- reftable_malloc_ptr\n  > reftable/basics.o\t- reftable_realloc_ptr\n  > reftable/basics.o\t- reftable_set_alloc\n  > reftable/block.o\t- block_reader_seek\n  > reftable/block.o\t- block_writer_register_restart\n  > reftable/file.o\t- file_vtable\n  > reftable/iter.o\t- empty_vtable\n  > reftable/iter.o\t- filtering_ref_iterator_vtable\n  > reftable/iter.o\t- indexed_table_ref_iter_vtable\n  > reftable/merged.o\t- merged_iter_vtable\n  > reftable/merged.o\t- reftable_merged_table_max_update_index\n  > reftable/merged.o\t- reftable_merged_table_min_update_index\n  > reftable/merged.o\t- reftable_merged_table_seek_log_at\n  > reftable/pq.o\t- merged_iter_pqueue_check\n  > reftable/pq.o\t- pq_less\n  > reftable/reader.o\t- block_source_close\n  > reftable/reader.o\t- block_source_read_block\n  > reftable/reader.o\t- block_source_size\n  > reftable/reader.o\t- init_reader\n  > reftable/reader.o\t- reftable_reader_hash_id\n  > reftable/reader.o\t- reftable_reader_refs_for\n  > reftable/reader.o\t- reftable_reader_seek_log\n  > reftable/reader.o\t- reftable_reader_seek_log_at\n  > reftable/reader.o\t- table_iter_vtable\n  > reftable/record.o\t- get_var_int\n  > reftable/record.o\t- index_record_vtable\n  > reftable/record.o\t- obj_record_vtable\n  > reftable/record.o\t- put_var_int\n  > reftable/record.o\t- record_as_log\n  > reftable/record.o\t- record_as_ref\n  > reftable/record.o\t- reftable_log_record_equal\n  > reftable/record.o\t- reftable_log_record_print\n  > reftable/record.o\t- reftable_log_record_vtable\n  > reftable/record.o\t- reftable_ref_record_equal\n  > reftable/record.o\t- reftable_ref_record_print\n  > reftable/record.o\t- reftable_ref_record_vtable\n  > reftable/slice.o\t- block_source_from_slice\n  > reftable/slice.o\t- malloc_block_source_instance\n  > reftable/slice.o\t- malloc_vtable\n  > reftable/slice.o\t- slice_equal\n  > reftable/slice.o\t- slice_vtable\n  > reftable/slice.o\t- slice_write\n  > reftable/slice.o\t- slice_write_void\n  > reftable/slice.o\t- slice_yield\n  > reftable/stack.o\t- fastlog2\n  > reftable/stack.o\t- read_lines\n  > reftable/stack.o\t- reftable_addition_add\n  > reftable/stack.o\t- reftable_addition_close\n  > reftable/stack.o\t- reftable_addition_commit\n  > reftable/stack.o\t- reftable_stack_auto_compact\n  > reftable/stack.o\t- reftable_stack_compaction_stats\n  > reftable/stack.o\t- reftable_stack_destroy\n  > reftable/stack.o\t- reftable_stack_new_addition\n  > reftable/stack.o\t- reftable_stack_read_log\n  > reftable/stack.o\t- reftable_stack_reload\n  > reftable/stack.o\t- sizes_to_segments\n  > reftable/stack.o\t- stack_try_add\n  > reftable/stack.o\t- stack_write_compact\n  > reftable/stack.o\t- suggest_compaction_segment\n  > reftable/writer.o\t- debug\n  > reftable/writer.o\t- writer_clear_index\n  > reftable/writer.o\t- writer_finish_public_section\n  > reftable/writer.o\t- writer_flush_block\n  > reftable/writer.o\t- writer_stats\n\nNote: I have not looked at any of the reftable patches/files.\n\nATB,\nRamsay Jones\n"},{"id":"396072","messageId":"20200423235809.GA1949@danh.dev","threadId":"53297","inReplyTo":"86ef24e2-3ab6-5e9c-900b-0eb4dbc1bb04@ramsayjones.plus.com","subject":"Re: [PATCH 0/4] fix make sparse warning","fromName":"Danh Doan","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-04-23T23:58:09Z","receivedAt":"2020-04-23T23:58:16Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2020-04-24 00:10:25+0100, Ramsay Jones <ramsay@ramsayjones.plus.com> wrote:\n> \n> \n> On 23/04/2020 14:47, Đoàn Trần Công Danh wrote:\n> > It's happened that I tried to run make check on project that support autoconf.\n> \n> I try to ignore autoconf as much as possible, so I don't know why people\n\nFor some reason, people refer to autotools as autohell\n\n> who use it regularly seem to expect a 'make check' target (is that anything\n> to do with ./config.status --recheck?).\n\nBecause it's autotools's recommendation.\nhttps://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Basic-Installation.html#Basic-Installation\nhttps://www.gnu.org/software/automake/manual/automake.html#Standard-Targets\n\nYes, Linux kernel, and Git don't like GNU Coding Standards (and me\nneither, because of their weird bracket position). But, it's\nreasonable expectation if autotools is used.\n\n> > Git's Makefile told me to run `make sparse` instead.\n> \n> In which case, you must have had sparse installed, otherwise you would\n> have been directed to 'make test'. [See commit 912f9980d2 (\"Makefile: help\n> people who run 'make check' by mistake\", 2008-11-11)]\n> \n> The 'check' target was introduced in commit 44c9e8594e (\"Fix up header file\n> dependencies and add sparse checking rules\", 2005-07-03). As you can see,\n> that target has nothing to do with autoconf/configure.\n> \n> Exactly a year later, support for autoconf tools was added in commit\n> 556677144b (\"autoconf: Use autoconf to write installation\n> directories to config.mak.autogen\", 2006-07-03). This provides an\n> 'alternative' to just\n> using the Makefile (which is the _primary_ method used to build git).\n> \n> I suspect that the majority of git developers don't use the autoconf\n> tools (I have no numbers, just gut feeling).\n\nI also think so.\n \n> I added the 'sparse' target in commit 0bcd9ae85d (\"sparse: Fix\n> errors due to missing target-specific variables\", 2011-04-21). After\n> nine years, we could\n> perhaps just drop the 'check' target altogether? dunno.\n> \n> > I /think/ if we have a rule in Makefile, we should adhere to it.\n> \n> Hmm, do you mean that 'make check' should be _reserved_ for autoconf use?\n> [fun fact: the test target in the sparse Makefile is 'check' :-D ]\n\nNo, I didn't mean that, I just want to fix sparse warning.\n\nI don't care much about the target's name,\nin fact, I prefer `make test` over `make check`.\n\nIf we don't really care about sparse warning.\nLet's remove this sparse target.\n\nBut, I think we do care about some sparse warning that modern compiler\nstopped caring about, like the one with final_new_line.\n\n> > I also fix another change in ds/blame-on-bloom, which I think it's worth to\n> > fix, see: <20200423133937.GA1984@danh.dev>\n> \n> Yes, looks good.\n> \n> > This series is developed from latest master.\n> \n> I have some comments on the patches (I'm running out of time here,\n> so I may not get to them till tomorrow).\n> \n> > It's conflicted when merge down next and pu.\n> > \n> > For next, please ignore the conflict with fmt-merge-msg.c and\n> > apply [5/4] instead.\n> > \n> > For pu, reftable.c has too much warnings, I'm too lazy to look into it.\n> \n> For those interested, the 'too much warnings' on the 'pu' branch looks\n> like (for pu@faf094bf11):\n> \n>   $ make sparse >psp-out 2>&1\n>   $ diff nsp-out psp-out\n>   154a155\n>   >     SP refs/reftable-backend.c\n>   406a408\n>   >     SP t/helper/test-proc-receive.c\n>   447a450,511\n>   >     SP reftable/basics.c\n>   > reftable/basics.c:157:6: warning: symbol 'reftable_malloc_ptr' was not declared. Should it be static?\n>   > reftable/basics.c:158:6: warning: symbol 'reftable_realloc_ptr' was not declared. Should it be static?\n>   > reftable/basics.c:159:6: warning: symbol 'reftable_free_ptr' was not declared. Should it be static?\n>   >     SP reftable/block.c\n>   >     SP reftable/bytes.c\n>   >     SP reftable/file.c\n>   > reftable/file.c:57:37: warning: symbol 'file_vtable' was not declared. Should it be static?\n>   >     SP reftable/iter.c\n>   > reftable/iter.c:32:33: warning: symbol 'empty_vtable' was not declared. Should it be static?\n>   > reftable/iter.c:61:31: warning: Using plain integer as NULL pointer\n>   > reftable/iter.c:69:31: warning: Using plain integer as NULL pointer\n>   > reftable/iter.c:96:57: warning: Using plain integer as NULL pointer\n>   > reftable/iter.c:124:33: warning: symbol 'filtering_ref_iterator_vtable' was not declared. Should it be static?\n>   > reftable/iter.c:224:33: warning: symbol 'indexed_table_ref_iter_vtable' was not declared. Should it be static?\n>   >     SP reftable/merged.c\n>   > reftable/merged.c:141:33: warning: symbol 'merged_iter_vtable' was not declared. Should it be static?\n>   > reftable/merged.c:283:31: warning: Using plain integer as NULL pointer\n>   > reftable/merged.c:296:31: warning: Using plain integer as NULL pointer\n>   >     SP reftable/pq.c\n>   >     SP reftable/reader.c\n>   > reftable/reader.c:180:42: warning: Using plain integer as NULL pointer\n>   > reftable/reader.c:181:42: warning: Using plain integer as NULL pointer\n>   > reftable/reader.c:284:41: warning: Using plain integer as NULL pointer\n>   > reftable/reader.c:360:44: warning: Using plain integer as NULL pointer\n>   > reftable/reader.c:396:33: warning: symbol 'table_iter_vtable' was not declared. Should it be static?\n>   > reftable/reader.c:450:36: warning: Using plain integer as NULL pointer\n>   > reftable/reader.c:498:42: warning: Using plain integer as NULL pointer\n>   > reftable/reader.c:500:44: warning: Using plain integer as NULL pointer\n>   > reftable/reader.c:501:42: warning: Using plain integer as NULL pointer\n>   > reftable/reader.c:502:36: warning: Using plain integer as NULL pointer\n>   > reftable/reader.c:565:34: warning: Using plain integer as NULL pointer\n>   > reftable/reader.c:610:31: warning: Using plain integer as NULL pointer\n>   > reftable/reader.c:623:31: warning: Using plain integer as NULL pointer\n>   > reftable/reader.c:669:36: warning: Using plain integer as NULL pointer\n>   > reftable/reader.c:670:42: warning: Using plain integer as NULL pointer\n>   > reftable/reader.c:671:35: warning: Using plain integer as NULL pointer\n>   > reftable/reader.c:672:35: warning: Using plain integer as NULL pointer\n>   >     SP reftable/record.c\n>   > reftable/record.c:556:22: warning: symbol 'obj_record_vtable' was not declared. Should it be static?\n>   > reftable/record.c:839:22: warning: symbol 'reftable_log_record_vtable' was not declared. Should it be static?\n>   > reftable/record.c:961:22: warning: symbol 'index_record_vtable' was not declared. Should it be static?\n>   >     SP reftable/slice.c\n>   > reftable/slice.c:180:37: warning: symbol 'slice_vtable' was not declared. Should it be static?\n>   > reftable/slice.c:200:37: warning: symbol 'malloc_vtable' was not declared. Should it be static?\n>   > reftable/slice.c:204:30: warning: symbol 'malloc_block_source_instance' was not declared. Should it be static?\n>   >     SP reftable/stack.c\n>   > reftable/stack.c:157:62: warning: Using plain integer as NULL pointer\n>   > reftable/stack.c:667:41: warning: Using plain integer as NULL pointer\n>   > reftable/stack.c:668:44: warning: Using plain integer as NULL pointer\n>   > reftable/stack.c:669:44: warning: Using plain integer as NULL pointer\n>   > reftable/stack.c:1085:41: warning: Using plain integer as NULL pointer\n>   > reftable/stack.c:1111:41: warning: Using plain integer as NULL pointer\n>   >     SP reftable/tree.c\n>   >     SP reftable/writer.c\n>   > reftable/writer.c:231:31: warning: Using plain integer as NULL pointer\n>   > reftable/writer.c:299:39: warning: Using plain integer as NULL pointer\n>   > reftable/writer.c:347:47: warning: Using plain integer as NULL pointer\n>   > reftable/writer.c:426:31: warning: Using plain integer as NULL pointer\n>   > reftable/writer.c:468:45: warning: Using plain integer as NULL pointer\n>   > reftable/writer.c:584:11: warning: symbol 'debug' was not declared. Should it be static?\n>   >     SP reftable/zlib-compat.c\n> \n> Also, my static-check perl script says the following symbols are not\n> used outside the file which defines them (so they could be marked static):\n\nAll of them are in reftable, and they're catched by `make sparse`,\ntoo.\n\n>   $ ./static-check.pl >psc\n>   $ diff nsc psc\n>   71a72,136\n>   > reftable/basics.o\t- reftable_free_ptr\n>   > reftable/basics.o\t- reftable_malloc_ptr\n>   > reftable/basics.o\t- reftable_realloc_ptr\n>   > reftable/basics.o\t- reftable_set_alloc\n>   > reftable/block.o\t- block_reader_seek\n>   > reftable/block.o\t- block_writer_register_restart\n>   > reftable/file.o\t- file_vtable\n>   > reftable/iter.o\t- empty_vtable\n>   > reftable/iter.o\t- filtering_ref_iterator_vtable\n>   > reftable/iter.o\t- indexed_table_ref_iter_vtable\n>   > reftable/merged.o\t- merged_iter_vtable\n>   > reftable/merged.o\t- reftable_merged_table_max_update_index\n>   > reftable/merged.o\t- reftable_merged_table_min_update_index\n>   > reftable/merged.o\t- reftable_merged_table_seek_log_at\n>   > reftable/pq.o\t- merged_iter_pqueue_check\n>   > reftable/pq.o\t- pq_less\n>   > reftable/reader.o\t- block_source_close\n>   > reftable/reader.o\t- block_source_read_block\n>   > reftable/reader.o\t- block_source_size\n>   > reftable/reader.o\t- init_reader\n>   > reftable/reader.o\t- reftable_reader_hash_id\n>   > reftable/reader.o\t- reftable_reader_refs_for\n>   > reftable/reader.o\t- reftable_reader_seek_log\n>   > reftable/reader.o\t- reftable_reader_seek_log_at\n>   > reftable/reader.o\t- table_iter_vtable\n>   > reftable/record.o\t- get_var_int\n>   > reftable/record.o\t- index_record_vtable\n>   > reftable/record.o\t- obj_record_vtable\n>   > reftable/record.o\t- put_var_int\n>   > reftable/record.o\t- record_as_log\n>   > reftable/record.o\t- record_as_ref\n>   > reftable/record.o\t- reftable_log_record_equal\n>   > reftable/record.o\t- reftable_log_record_print\n>   > reftable/record.o\t- reftable_log_record_vtable\n>   > reftable/record.o\t- reftable_ref_record_equal\n>   > reftable/record.o\t- reftable_ref_record_print\n>   > reftable/record.o\t- reftable_ref_record_vtable\n>   > reftable/slice.o\t- block_source_from_slice\n>   > reftable/slice.o\t- malloc_block_source_instance\n>   > reftable/slice.o\t- malloc_vtable\n>   > reftable/slice.o\t- slice_equal\n>   > reftable/slice.o\t- slice_vtable\n>   > reftable/slice.o\t- slice_write\n>   > reftable/slice.o\t- slice_write_void\n>   > reftable/slice.o\t- slice_yield\n>   > reftable/stack.o\t- fastlog2\n>   > reftable/stack.o\t- read_lines\n>   > reftable/stack.o\t- reftable_addition_add\n>   > reftable/stack.o\t- reftable_addition_close\n>   > reftable/stack.o\t- reftable_addition_commit\n>   > reftable/stack.o\t- reftable_stack_auto_compact\n>   > reftable/stack.o\t- reftable_stack_compaction_stats\n>   > reftable/stack.o\t- reftable_stack_destroy\n>   > reftable/stack.o\t- reftable_stack_new_addition\n>   > reftable/stack.o\t- reftable_stack_read_log\n>   > reftable/stack.o\t- reftable_stack_reload\n>   > reftable/stack.o\t- sizes_to_segments\n>   > reftable/stack.o\t- stack_try_add\n>   > reftable/stack.o\t- stack_write_compact\n>   > reftable/stack.o\t- suggest_compaction_segment\n>   > reftable/writer.o\t- debug\n>   > reftable/writer.o\t- writer_clear_index\n>   > reftable/writer.o\t- writer_finish_public_section\n>   > reftable/writer.o\t- writer_flush_block\n>   > reftable/writer.o\t- writer_stats\n> \n> Note: I have not looked at any of the reftable patches/files.\n\nMe neither.\n\n-- \nDanh\n"},{"id":"396080","messageId":"1df91aa4-dda5-64da-6ae3-5d65e50a55c5@ramsayjones.plus.com","threadId":"53297","inReplyTo":"c4fac2ae9d10bc426cb26e4a102b808549696763.1587648870.git.congdanhqx@gmail.com","subject":"Re: [PATCH 1/4] C: s/0/NULL/ for pointer type","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2020-04-24T00:39:42Z","receivedAt":"2020-04-24T00:39:48Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 23/04/2020 14:47, Đoàn Trần Công Danh wrote:\n> Fix warning from  `make sparse`.\n\nYou may want to split the changes to 't/helper/test-parse-pathspec-file.c'\ninto its own patch, since those changes are not potentially controversial.\n\nThe remainder of this patch follows a pattern that I used in a patch that\nwas rejected; see https://public-inbox.org/git/e6796c60-a870-e761-3b07-b680f934c537@ramsayjones.plus.com/, et seq.\n\nActually, I have a patch somewhere which suppressed the sparse warning\nfor the '= { 0 }' token sequence used in these initializations. However,\nI don't seem to be able to find them at the moment! :(\n\n[Luc, this topic came up on the sparse and kernel mailing-lists at one\npoint, but I didn't get around to posting my patch to the list - something\ncame up. Hopefully, I will find some time to find it and post it soon.]\n\nATB,\nRamsay Jones\n\n> \n> Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>\n> ---\n>  add-interactive.c                   | 2 +-\n>  builtin/fmt-merge-msg.c             | 2 +-\n>  log-tree.c                          | 4 ++--\n>  range-diff.c                        | 2 +-\n>  t/helper/test-parse-pathspec-file.c | 6 +++---\n>  5 files changed, 8 insertions(+), 8 deletions(-)\n> \n> diff --git a/add-interactive.c b/add-interactive.c\n> index 29cd2fe020..b8983838b9 100644\n> --- a/add-interactive.c\n> +++ b/add-interactive.c\n> @@ -526,7 +526,7 @@ static int get_modified_files(struct repository *r,\n>  \n>  \tfor (i = 0; i < 2; i++) {\n>  \t\tstruct rev_info rev;\n> -\t\tstruct setup_revision_opt opt = { 0 };\n> +\t\tstruct setup_revision_opt opt = { NULL };\n>  \n>  \t\tif (filter == INDEX_ONLY)\n>  \t\t\ts.mode = (i == 0) ? FROM_INDEX : FROM_WORKTREE;\n> diff --git a/builtin/fmt-merge-msg.c b/builtin/fmt-merge-msg.c\n> index 172dfbd852..f4376bccef 100644\n> --- a/builtin/fmt-merge-msg.c\n> +++ b/builtin/fmt-merge-msg.c\n> @@ -494,7 +494,7 @@ static void fmt_merge_msg_sigs(struct strbuf *out)\n>  \t\tenum object_type type;\n>  \t\tunsigned long size, len;\n>  \t\tchar *buf = read_object_file(oid, &type, &size);\n> -\t\tstruct signature_check sigc = { 0 };\n> +\t\tstruct signature_check sigc = { NULL };\n>  \t\tstruct strbuf sig = STRBUF_INIT;\n>  \n>  \t\tif (!buf || type != OBJ_TAG)\n> diff --git a/log-tree.c b/log-tree.c\n> index 0064788b25..ca721150d4 100644\n> --- a/log-tree.c\n> +++ b/log-tree.c\n> @@ -449,7 +449,7 @@ static void show_signature(struct rev_info *opt, struct commit *commit)\n>  {\n>  \tstruct strbuf payload = STRBUF_INIT;\n>  \tstruct strbuf signature = STRBUF_INIT;\n> -\tstruct signature_check sigc = { 0 };\n> +\tstruct signature_check sigc = { NULL };\n>  \tint status;\n>  \n>  \tif (parse_signed_commit(commit, &payload, &signature) <= 0)\n> @@ -496,7 +496,7 @@ static int show_one_mergetag(struct commit *commit,\n>  \tstruct object_id oid;\n>  \tstruct tag *tag;\n>  \tstruct strbuf verify_message;\n> -\tstruct signature_check sigc = { 0 };\n> +\tstruct signature_check sigc = { NULL };\n>  \tint status, nth;\n>  \tsize_t payload_size;\n>  \n> diff --git a/range-diff.c b/range-diff.c\n> index f745567cf6..71dcd947c5 100644\n> --- a/range-diff.c\n> +++ b/range-diff.c\n> @@ -107,7 +107,7 @@ static int read_patches(const char *range, struct string_list *list,\n>  \t\t}\n>  \n>  \t\tif (starts_with(line, \"diff --git\")) {\n> -\t\t\tstruct patch patch = { 0 };\n> +\t\t\tstruct patch patch = { NULL };\n>  \t\t\tstruct strbuf root = STRBUF_INIT;\n>  \t\t\tint linenr = 0;\n>  \n> diff --git a/t/helper/test-parse-pathspec-file.c b/t/helper/test-parse-pathspec-file.c\n> index 02f4ccfd2a..b3e08cef4b 100644\n> --- a/t/helper/test-parse-pathspec-file.c\n> +++ b/t/helper/test-parse-pathspec-file.c\n> @@ -6,7 +6,7 @@\n>  int cmd__parse_pathspec_file(int argc, const char **argv)\n>  {\n>  \tstruct pathspec pathspec;\n> -\tconst char *pathspec_from_file = 0;\n> +\tconst char *pathspec_from_file = NULL;\n>  \tint pathspec_file_nul = 0, i;\n>  \n>  \tstatic const char *const usage[] = {\n> @@ -20,9 +20,9 @@ int cmd__parse_pathspec_file(int argc, const char **argv)\n>  \t\tOPT_END()\n>  \t};\n>  \n> -\tparse_options(argc, argv, 0, options, usage, 0);\n> +\tparse_options(argc, argv, NULL, options, usage, 0);\n>  \n> -\tparse_pathspec_file(&pathspec, 0, 0, 0, pathspec_from_file,\n> +\tparse_pathspec_file(&pathspec, 0, 0, NULL, pathspec_from_file,\n>  \t\t\t    pathspec_file_nul);\n>  \n>  \tfor (i = 0; i < pathspec.nr; i++)\n> \n"},{"id":"396084","messageId":"62642f8c-e885-9fb6-f13b-a9960a2172a5@ramsayjones.plus.com","threadId":"53297","inReplyTo":"25f595f56f7f895ab31bf7269aabad9142c0590c.1587648870.git.congdanhqx@gmail.com","subject":"Re: [PATCH 2/4] compat/regex: silence `make sparse` warning","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2020-04-24T00:51:40Z","receivedAt":"2020-04-24T00:51:46Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 23/04/2020 14:47, Đoàn Trần Công Danh wrote:\n> * alloca: somewhere later in the code, we indirectly include alloca.h\n> which will define alloca again, include it prior to define alloca in\n> order to not define it against.\n> \n> * Copy all attributes from the header to source file, and move the\n>   attributes prior to function name. cgcc is very picky on the position\n>   of attribute.\n\nThis patch is no longer needed (iff you use a bleeding edge version of\nsparse), since this was fixed in commit 172f6a98 (\"let function definition inherit prototype attributes\", 2019-11-19).\n\n  $ git describe 172f6a98\n  v0.6.1-37-g172f6a98\n  $ \n\nAh, so this fix is not in any released version of sparse (v0.6.1 is the\ncurrent release - I always build/run the tip of the 'master' branch from\nthe sparse git repo).\n\nI starred at this warning for years (on cygwin, I don't build with NO_REGEX\non Linux), but I didn't send a patch for it because it was a sparse fault.\n\nATB,\nRamsay Jones\n\n> \n> Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>\n> ---\n>  compat/regex/regex.c          | 1 +\n>  compat/regex/regex_internal.c | 2 +-\n>  compat/regex/regex_internal.h | 5 ++---\n>  3 files changed, 4 insertions(+), 4 deletions(-)\n> \n> diff --git a/compat/regex/regex.c b/compat/regex/regex.c\n> index f3e03a9eab..4bef75a716 100644\n> --- a/compat/regex/regex.c\n> +++ b/compat/regex/regex.c\n> @@ -62,6 +62,7 @@\n>  #include <stdint.h>\n>  \n>  #ifdef GAWK\n> +#include <alloca.h>\n>  #undef alloca\n>  #define alloca alloca_is_bad_you_should_never_use_it\n>  #endif\n> diff --git a/compat/regex/regex_internal.c b/compat/regex/regex_internal.c\n> index ec51cf3446..58504f795b 100644\n> --- a/compat/regex/regex_internal.c\n> +++ b/compat/regex/regex_internal.c\n> @@ -921,7 +921,7 @@ re_string_destruct (re_string_t *pstr)\n>  /* Return the context at IDX in INPUT.  */\n>  \n>  static unsigned int\n> -internal_function\n> +internal_function __attribute ((pure))\n>  re_string_context_at (const re_string_t *input, int idx, int eflags)\n>  {\n>    int c;\n> diff --git a/compat/regex/regex_internal.h b/compat/regex/regex_internal.h\n> index 3ee8aae59d..c61a1e4971 100644\n> --- a/compat/regex/regex_internal.h\n> +++ b/compat/regex/regex_internal.h\n> @@ -430,9 +430,8 @@ static reg_errcode_t build_wcs_upper_buffer (re_string_t *pstr)\n>  # endif /* RE_ENABLE_I18N */\n>  static void build_upper_buffer (re_string_t *pstr) internal_function;\n>  static void re_string_translate_buffer (re_string_t *pstr) internal_function;\n> -static unsigned int re_string_context_at (const re_string_t *input, int idx,\n> -\t\t\t\t\t  int eflags)\n> -     internal_function __attribute ((pure));\n> +static internal_function __attribute ((pure))\n> +unsigned int re_string_context_at (const re_string_t *input, int idx, int eflags);\n>  #endif\n>  #define re_string_peek_byte(pstr, offset) \\\n>    ((pstr)->mbs[(pstr)->cur_idx + offset])\n> \n"},{"id":"396085","messageId":"351abde3-6ae4-dc65-a846-3b45202a07ec@ramsayjones.plus.com","threadId":"53297","inReplyTo":"5bd7b929107c277e10a697bc874b702b85691558.1587648870.git.congdanhqx@gmail.com","subject":"Re: [PATCH 3/4] graph.c: limit linkage of internal variable","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2020-04-24T00:52:58Z","receivedAt":"2020-04-24T00:53:04Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 23/04/2020 14:47, Đoàn Trần Công Danh wrote:\n> Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>\n> ---\n>  graph.c | 2 +-\n>  1 file changed, 1 insertion(+), 1 deletion(-)\n> \n> diff --git a/graph.c b/graph.c\n> index 4fb25ad464..4cd9915075 100644\n> --- a/graph.c\n> +++ b/graph.c\n> @@ -1055,7 +1055,7 @@ static void graph_output_commit_line(struct git_graph *graph, struct graph_line\n>  \t\tgraph_update_state(graph, GRAPH_COLLAPSING);\n>  }\n>  \n> -const char merge_chars[] = {'/', '|', '\\\\'};\n> +static const char merge_chars[] = {'/', '|', '\\\\'};\n>  \n>  static void graph_output_post_merge_line(struct git_graph *graph, struct graph_line *line)\n>  {\n> \n\nYep, LGTM.\n\nATB,\nRamsay Jones\n\n"},{"id":"396086","messageId":"xmqqd07xem9l.fsf@gitster.c.googlers.com","threadId":"53297","inReplyTo":"1df91aa4-dda5-64da-6ae3-5d65e50a55c5@ramsayjones.plus.com","subject":"Re: [PATCH 1/4] C: s/0/NULL/ for pointer type","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-04-24T00:54:30Z","receivedAt":"2020-04-24T00:54:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramsay Jones <ramsay@ramsayjones.plus.com> writes:\n\n> Actually, I have a patch somewhere which suppressed the sparse warning\n> for the '= { 0 }' token sequence used in these initializations. However,\n> I don't seem to be able to find them at the moment! :(\n\nAHHHHHhhhhhhhh.  \n\nThanks for reminding.  Yeah, I recall that the concensus of those\nwho were vocal in that old discussion [*1*] was that \"= { 0 }\"\nshould be taken as an idiom and should not be subject to s/0/NULL/\nconversion.\n\n> [Luc, this topic came up on the sparse and kernel mailing-lists at one\n> point, but I didn't get around to posting my patch to the list - something\n> came up. Hopefully, I will find some time to find it and post it soon.]\n\n\n[References]\n\n*1*\n\nhttps://lore.kernel.org/git/e6796c60-a870-e761-3b07-b680f934c537@ramsayjones.plus.com/\n"},{"id":"396087","messageId":"cbe8fcac-d7d5-8db2-cf69-6f04136337c9@ramsayjones.plus.com","threadId":"53297","inReplyTo":"dddf2d402702a616e04e7e446e31e0c6697d8c49.1587648870.git.congdanhqx@gmail.com","subject":"Re: [PATCH 4/4] progress.c: silence cgcc suggestion about internal linkage","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2020-04-24T00:58:51Z","receivedAt":"2020-04-24T00:58:57Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 23/04/2020 14:47, Đoàn Trần Công Danh wrote:\n> Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>\n> ---\n>  progress.c | 2 ++\n>  1 file changed, 2 insertions(+)\n> \n> diff --git a/progress.c b/progress.c\n> index 19805ac646..fb53a2ec0c 100644\n> --- a/progress.c\n> +++ b/progress.c\n> @@ -50,7 +50,9 @@ static volatile sig_atomic_t progress_update;\n>   * These are only intended for testing the progress output, i.e. exclusively\n>   * for 'test-tool progress'.\n>   */\n> +extern int progress_testing; /* to silence sparse: internal linkage */\n>  int progress_testing;\n> +extern uint64_t progress_test_ns; /* to silence sparse: internal linkage */\n>  uint64_t progress_test_ns = 0;\n>  void progress_test_force_update(void); /* To silence -Wmissing-prototypes */\n>  void progress_test_force_update(void)\n\nMy preference would be to add these extern declarations to the\nprogress.h header file, with a note that they are only used by\nthe 't/helper/test-progress.c' test helper. (Also, remove the\nextern declarations from test-progress.c, of course).\n\nBut this works as well. :D\n\nATB,\nRamsay Jones\n\n"},{"id":"396089","messageId":"20200424010425.GE1949@danh.dev","threadId":"53297","inReplyTo":"62642f8c-e885-9fb6-f13b-a9960a2172a5@ramsayjones.plus.com","subject":"Re: [PATCH 2/4] compat/regex: silence `make sparse` warning","fromName":"Danh Doan","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-04-24T01:04:25Z","receivedAt":"2020-04-24T01:04:32Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2020-04-24 01:51:40+0100, Ramsay Jones <ramsay@ramsayjones.plus.com> wrote:\n> \n> \n> On 23/04/2020 14:47, Đoàn Trần Công Danh wrote:\n> > * alloca: somewhere later in the code, we indirectly include alloca.h\n> > which will define alloca again, include it prior to define alloca in\n> > order to not define it against.\n> > \n> > * Copy all attributes from the header to source file, and move the\n> >   attributes prior to function name. cgcc is very picky on the position\n> >   of attribute.\n> \n> This patch is no longer needed (iff you use a bleeding edge version of\n> sparse), since this was fixed in commit 172f6a98 (\"let function definition inherit prototype attributes\", 2019-11-19).\n> \n>   $ git describe 172f6a98\n>   v0.6.1-37-g172f6a98\n>   $ \n> \n> Ah, so this fix is not in any released version of sparse (v0.6.1 is the\n> current release - I always build/run the tip of the 'master' branch from\n> the sparse git repo).\n\nCorrect, when I saw your bleeding edge, I check my sparse version. It\nsays 0.6.1\n\n> I starred at this warning for years (on cygwin, I don't build with NO_REGEX\n> on Linux), but I didn't send a patch for it because it was a sparse fault.\n\nIt's sparse' fault, of course, I talked about its pickiness in the\ncommit message after all.\n\nBut, we still need the alloca part of this patch.\n\n-- \nDanh\n"},{"id":"396090","messageId":"20200424010924.GF1949@danh.dev","threadId":"53297","inReplyTo":"xmqqd07xem9l.fsf@gitster.c.googlers.com","subject":"Re: [PATCH 1/4] C: s/0/NULL/ for pointer type","fromName":"Danh Doan","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-04-24T01:09:24Z","receivedAt":"2020-04-24T01:09:28Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2020-04-23 17:54:30-0700, Junio C Hamano <gitster@pobox.com> wrote:\n> Ramsay Jones <ramsay@ramsayjones.plus.com> writes:\n> \n> > Actually, I have a patch somewhere which suppressed the sparse warning\n> > for the '= { 0 }' token sequence used in these initializations. However,\n> > I don't seem to be able to find them at the moment! :(\n> \n> AHHHHHhhhhhhhh.  \n> \n> Thanks for reminding.  Yeah, I recall that the concensus of those\n> who were vocal in that old discussion [*1*] was that \"= { 0 }\"\n> should be taken as an idiom and should not be subject to s/0/NULL/\n> conversion.\n\nSo, to follow that idiom, this patch should be changed, too?\nhttps://lore.kernel.org/git/nycvar.QRO.7.76.6.2004101604210.46@tvgsbejvaqbjf.bet/\n\n+Cc: Dscho and Han-Wen\n\n> > [Luc, this topic came up on the sparse and kernel mailing-lists at one\n> > point, but I didn't get around to posting my patch to the list - something\n> > came up. Hopefully, I will find some time to find it and post it soon.]\n> \n> \n> [References]\n> \n> *1*\n> \n> https://lore.kernel.org/git/e6796c60-a870-e761-3b07-b680f934c537@ramsayjones.plus.com/\n\n-- \nDanh\n"},{"id":"396091","messageId":"xmqq8silejib.fsf@gitster.c.googlers.com","threadId":"53297","inReplyTo":"20200424010924.GF1949@danh.dev","subject":"Re: [PATCH 1/4] C: s/0/NULL/ for pointer type","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-04-24T01:54:04Z","receivedAt":"2020-04-24T01:54:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Danh Doan <congdanhqx@gmail.com> writes:\n\n> So, to follow that idiom, this patch should be changed, too?\n> https://lore.kernel.org/git/nycvar.QRO.7.76.6.2004101604210.46@tvgsbejvaqbjf.bet/\n\nI didn't look at that patch carefully, but it seems that it changes\n\n\tstruct foo variable_to_be_initialized = {};\n\ninto various forms, e.g.\n\n\tstruct foo variable_to_be_initialized = { NULL };\n\tstruct foo variable_to_be_initialized = { { NULL } };\n\ndepending on the actual shape of 'foo', and that old thread explains\nthat it is sufficient to consistently write \"= { 0 };\". \n\nHaving said that, if I recall correctly, Dscho suggested even larger\nstyle fixes to the code, so if that were to happen, the above initializer\nfix may just be lost in the noise ;-)\n\nThanks.\n\n> +Cc: Dscho and Han-Wen\n>\n>> > [Luc, this topic came up on the sparse and kernel mailing-lists at one\n>> > point, but I didn't get around to posting my patch to the list - something\n>> > came up. Hopefully, I will find some time to find it and post it soon.]\n>> \n>> \n>> [References]\n>> \n>> *1*\n>> \n>> https://lore.kernel.org/git/e6796c60-a870-e761-3b07-b680f934c537@ramsayjones.plus.com/\n"},{"id":"396112","messageId":"20200424055417.GH1648190@coredump.intra.peff.net","threadId":"53297","inReplyTo":"cbe8fcac-d7d5-8db2-cf69-6f04136337c9@ramsayjones.plus.com","subject":"Re: [PATCH 4/4] progress.c: silence cgcc suggestion about internal linkage","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-04-24T05:54:17Z","receivedAt":"2020-04-24T05:54:19Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 24, 2020 at 01:58:51AM +0100, Ramsay Jones wrote:\n\n> > +extern int progress_testing; /* to silence sparse: internal linkage */\n> >  int progress_testing;\n> > +extern uint64_t progress_test_ns; /* to silence sparse: internal linkage */\n> >  uint64_t progress_test_ns = 0;\n> >  void progress_test_force_update(void); /* To silence -Wmissing-prototypes */\n> >  void progress_test_force_update(void)\n> \n> My preference would be to add these extern declarations to the\n> progress.h header file, with a note that they are only used by\n> the 't/helper/test-progress.c' test helper. (Also, remove the\n> extern declarations from test-progress.c, of course).\n\nI came here to say the same thing.\n\nAs a bonus, it would catch any changes to the types in the future\n(rather than just segfaulting when test-progress.c attempts to use an\nout-of-date type).\n\n-Peff\n"},{"id":"396139","messageId":"cover.1587740959.git.congdanhqx@gmail.com","threadId":"53297","inReplyTo":"cover.1587648870.git.congdanhqx@gmail.com","subject":"[PATCH v2 0/4] Fix Sparse Warning","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-04-24T15:12:29Z","receivedAt":"2020-04-24T15:12:42Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"Change in v2 from v1:\n* = { 0 } is an idiom to zero the structure, it shouldn't be changed\n* change in [4/4] for prototype\n* ignore diffent function prototype\n\nĐoàn Trần Công Danh (4):\n  test-parse-pathspec-file.c: s/0/NULL/ for pointer type\n  compat/regex: include alloca.h before undef it\n  graph.c: limit linkage of internal variable\n  progress.c: silence cgcc suggestion about internal linkage\n\n compat/regex/regex.c                | 1 +\n graph.c                             | 2 +-\n progress.c                          | 2 +-\n progress.h                          | 8 ++++++++\n t/helper/test-parse-pathspec-file.c | 6 +++---\n t/helper/test-progress.c            | 9 +--------\n 6 files changed, 15 insertions(+), 13 deletions(-)\n\n-- \n2.26.2.384.g435bf60bd5\n\n"},{"id":"396140","messageId":"c9a1812abfc1d2ec804105b703f44639c0f8e3e7.1587740959.git.congdanhqx@gmail.com","threadId":"53297","inReplyTo":"cover.1587740959.git.congdanhqx@gmail.com","subject":"[PATCH v2 1/4] test-parse-pathspec-file.c: s/0/NULL/ for pointer type","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-04-24T15:12:30Z","receivedAt":"2020-04-24T15:12:43Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>\n---\n t/helper/test-parse-pathspec-file.c | 6 +++---\n 1 file changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/t/helper/test-parse-pathspec-file.c b/t/helper/test-parse-pathspec-file.c\nindex 02f4ccfd2a..b3e08cef4b 100644\n--- a/t/helper/test-parse-pathspec-file.c\n+++ b/t/helper/test-parse-pathspec-file.c\n@@ -6,7 +6,7 @@\n int cmd__parse_pathspec_file(int argc, const char **argv)\n {\n \tstruct pathspec pathspec;\n-\tconst char *pathspec_from_file = 0;\n+\tconst char *pathspec_from_file = NULL;\n \tint pathspec_file_nul = 0, i;\n \n \tstatic const char *const usage[] = {\n@@ -20,9 +20,9 @@ int cmd__parse_pathspec_file(int argc, const char **argv)\n \t\tOPT_END()\n \t};\n \n-\tparse_options(argc, argv, 0, options, usage, 0);\n+\tparse_options(argc, argv, NULL, options, usage, 0);\n \n-\tparse_pathspec_file(&pathspec, 0, 0, 0, pathspec_from_file,\n+\tparse_pathspec_file(&pathspec, 0, 0, NULL, pathspec_from_file,\n \t\t\t    pathspec_file_nul);\n \n \tfor (i = 0; i < pathspec.nr; i++)\n-- \n2.26.2.384.g435bf60bd5\n\n"},{"id":"396141","messageId":"290ba923b5ee5bcaa4801454b6692deb532bd681.1587740959.git.congdanhqx@gmail.com","threadId":"53297","inReplyTo":"cover.1587740959.git.congdanhqx@gmail.com","subject":"[PATCH v2 2/4] compat/regex: include alloca.h before undef it","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-04-24T15:12:31Z","receivedAt":"2020-04-24T15:12:46Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"Somewhere later in the code, we indirectly include alloca.h\nwhich will define alloca again, thus create a warning about\nredefinition of a preprocessor.\n\nInclude it prior to define alloca in order to not define it again.\n\nSigned-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>\n---\n compat/regex/regex.c | 1 +\n 1 file changed, 1 insertion(+)\n\ndiff --git a/compat/regex/regex.c b/compat/regex/regex.c\nindex f3e03a9eab..4bef75a716 100644\n--- a/compat/regex/regex.c\n+++ b/compat/regex/regex.c\n@@ -62,6 +62,7 @@\n #include <stdint.h>\n \n #ifdef GAWK\n+#include <alloca.h>\n #undef alloca\n #define alloca alloca_is_bad_you_should_never_use_it\n #endif\n-- \n2.26.2.384.g435bf60bd5\n\n"},{"id":"396142","messageId":"39f8d85c2f16081415741351c16fb34d74924d3c.1587740959.git.congdanhqx@gmail.com","threadId":"53297","inReplyTo":"cover.1587740959.git.congdanhqx@gmail.com","subject":"[PATCH v2 3/4] graph.c: limit linkage of internal variable","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-04-24T15:12:32Z","receivedAt":"2020-04-24T15:12:47Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>\n---\n graph.c | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/graph.c b/graph.c\nindex 4fb25ad464..4cd9915075 100644\n--- a/graph.c\n+++ b/graph.c\n@@ -1055,7 +1055,7 @@ static void graph_output_commit_line(struct git_graph *graph, struct graph_line\n \t\tgraph_update_state(graph, GRAPH_COLLAPSING);\n }\n \n-const char merge_chars[] = {'/', '|', '\\\\'};\n+static const char merge_chars[] = {'/', '|', '\\\\'};\n \n static void graph_output_post_merge_line(struct git_graph *graph, struct graph_line *line)\n {\n-- \n2.26.2.384.g435bf60bd5\n\n"},{"id":"396143","messageId":"41eecf18edf3772ba04aebd656018e36058182d6.1587740959.git.congdanhqx@gmail.com","threadId":"53297","inReplyTo":"cover.1587740959.git.congdanhqx@gmail.com","subject":"[PATCH v2 4/4] progress.c: silence cgcc suggestion about internal linkage","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-04-24T15:12:33Z","receivedAt":"2020-04-24T15:12:49Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>\n---\n progress.c               | 2 +-\n progress.h               | 8 ++++++++\n t/helper/test-progress.c | 9 +--------\n 3 files changed, 10 insertions(+), 9 deletions(-)\n\ndiff --git a/progress.c b/progress.c\nindex 19805ac646..75633e9c5e 100644\n--- a/progress.c\n+++ b/progress.c\n@@ -8,6 +8,7 @@\n  * published by the Free Software Foundation.\n  */\n \n+#define GIT_TEST_PROGRESS_ONLY\n #include \"cache.h\"\n #include \"gettext.h\"\n #include \"progress.h\"\n@@ -52,7 +53,6 @@ static volatile sig_atomic_t progress_update;\n  */\n int progress_testing;\n uint64_t progress_test_ns = 0;\n-void progress_test_force_update(void); /* To silence -Wmissing-prototypes */\n void progress_test_force_update(void)\n {\n \tprogress_update = 1;\ndiff --git a/progress.h b/progress.h\nindex 847338911f..f1913acf73 100644\n--- a/progress.h\n+++ b/progress.h\n@@ -3,6 +3,14 @@\n \n struct progress;\n \n+#ifdef GIT_TEST_PROGRESS_ONLY\n+\n+extern int progress_testing;\n+extern uint64_t progress_test_ns;\n+void progress_test_force_update(void);\n+\n+#endif\n+\n void display_throughput(struct progress *progress, uint64_t total);\n void display_progress(struct progress *progress, uint64_t n);\n struct progress *start_progress(const char *title, uint64_t total);\ndiff --git a/t/helper/test-progress.c b/t/helper/test-progress.c\nindex 42b96cb103..5d05cbe789 100644\n--- a/t/helper/test-progress.c\n+++ b/t/helper/test-progress.c\n@@ -13,20 +13,13 @@\n  *\n  * See 't0500-progress-display.sh' for examples.\n  */\n+#define GIT_TEST_PROGRESS_ONLY\n #include \"test-tool.h\"\n #include \"gettext.h\"\n #include \"parse-options.h\"\n #include \"progress.h\"\n #include \"strbuf.h\"\n \n-/*\n- * These are defined in 'progress.c', but are not exposed in 'progress.h',\n- * because they are exclusively for testing.\n- */\n-extern int progress_testing;\n-extern uint64_t progress_test_ns;\n-void progress_test_force_update(void);\n-\n int cmd__progress(int argc, const char **argv)\n {\n \tint total = 0;\n-- \n2.26.2.384.g435bf60bd5\n\n"},{"id":"396146","messageId":"4ff17acf-42dc-5a00-bb61-b055144075eb@ramsayjones.plus.com","threadId":"53297","inReplyTo":"20200423235809.GA1949@danh.dev","subject":"Re: [PATCH 0/4] fix make sparse warning","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2020-04-24T16:38:31Z","receivedAt":"2020-04-24T16:46:07Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 24/04/2020 00:58, Danh Doan wrote:\n> On 2020-04-24 00:10:25+0100, Ramsay Jones <ramsay@ramsayjones.plus.com> wrote:\n>> On 23/04/2020 14:47, Đoàn Trần Công Danh wrote:\n>>> It's happened that I tried to run make check on project that support autoconf.\n>>\n>> I try to ignore autoconf as much as possible, so I don't know why people\n> \n> For some reason, people refer to autotools as autohell\n> \n>> who use it regularly seem to expect a 'make check' target (is that anything\n>> to do with ./config.status --recheck?).\n> \n> Because it's autotools's recommendation.\n> https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Basic-Installation.html#Basic-Installation\n> https://www.gnu.org/software/automake/manual/automake.html#Standard-Targets\n\nAh, OK, that explains alot! :D\n\nI have never seen that documented before, so thanks for the reference.\nHaving said that, most all 'autotools' projects I have seen have had\nan 'make test' target and _not_ 'make check'! (Well, thinking about\nit, none of those were actual GNU projects - maybe that's the difference).\n\n[snip]\n>> For those interested, the 'too much warnings' on the 'pu' branch looks\n>> like (for pu@faf094bf11):\n>>\n>>   $ make sparse >psp-out 2>&1\n>>   $ diff nsp-out psp-out\n>>   154a155\n>>   >     SP refs/reftable-backend.c\n>>   406a408\n>>   >     SP t/helper/test-proc-receive.c\n>>   447a450,511\n>>   >     SP reftable/basics.c\n>>   > reftable/basics.c:157:6: warning: symbol 'reftable_malloc_ptr' was not declared. Should it be static?\n>>   > reftable/basics.c:158:6: warning: symbol 'reftable_realloc_ptr' was not declared. Should it be static?\n>>   > reftable/basics.c:159:6: warning: symbol 'reftable_free_ptr' was not declared. Should it be static?\n\n[snip]\n\n>>   >     SP reftable/writer.c\n>>   > reftable/writer.c:231:31: warning: Using plain integer as NULL pointer\n>>   > reftable/writer.c:299:39: warning: Using plain integer as NULL pointer\n>>   > reftable/writer.c:347:47: warning: Using plain integer as NULL pointer\n>>   > reftable/writer.c:426:31: warning: Using plain integer as NULL pointer\n>>   > reftable/writer.c:468:45: warning: Using plain integer as NULL pointer\n>>   > reftable/writer.c:584:11: warning: symbol 'debug' was not declared. Should it be static?\n>>   >     SP reftable/zlib-compat.c\n>>\n>> Also, my static-check perl script says the following symbols are not\n>> used outside the file which defines them (so they could be marked static):\n> \n> All of them are in reftable, and they're catched by `make sparse`,\n> too.\n\nYeah, I didn't even look at the output. ;-)\n\nHowever, the output from static-check.pl is usually a super-set\nof the those from sparse - because sparse is really only looking\nat the declarations (or lack thereof) in one compilation unit.\nIn contrast, static-check.pl looks at all object files to tie up\ndefinitions with use (so across compilation units). (which is also\nwhy you have to be careful not to leave stale '*.o' files laying\naround when switching branches).\n\nATB,\nRamsay Jones\n\n"},{"id":"396147","messageId":"411ec3ea-162e-8e52-0133-3108e0c38f0d@ramsayjones.plus.com","threadId":"53297","inReplyTo":"cover.1587740959.git.congdanhqx@gmail.com","subject":"Re: [PATCH v2 0/4] Fix Sparse Warning","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2020-04-24T16:40:08Z","receivedAt":"2020-04-24T16:47:45Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 24/04/2020 16:12, Đoàn Trần Công Danh wrote:\n> Change in v2 from v1:\n> * = { 0 } is an idiom to zero the structure, it shouldn't be changed\n> * change in [4/4] for prototype\n> * ignore diffent function prototype\n\nApart from the regex patch [2/4], these all look good to me.\n\nThanks!\n\nATB,\nRamsay Jones\n\n> \n> Đoàn Trần Công Danh (4):\n>   test-parse-pathspec-file.c: s/0/NULL/ for pointer type\n>   compat/regex: include alloca.h before undef it\n>   graph.c: limit linkage of internal variable\n>   progress.c: silence cgcc suggestion about internal linkage\n> \n>  compat/regex/regex.c                | 1 +\n>  graph.c                             | 2 +-\n>  progress.c                          | 2 +-\n>  progress.h                          | 8 ++++++++\n>  t/helper/test-parse-pathspec-file.c | 6 +++---\n>  t/helper/test-progress.c            | 9 +--------\n>  6 files changed, 15 insertions(+), 13 deletions(-)\n> \n"},{"id":"396150","messageId":"820d44c5-5852-fa83-a814-8e58dd120565@ramsayjones.plus.com","threadId":"53297","inReplyTo":"290ba923b5ee5bcaa4801454b6692deb532bd681.1587740959.git.congdanhqx@gmail.com","subject":"Re: [PATCH v2 2/4] compat/regex: include alloca.h before undef it","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2020-04-24T16:56:46Z","receivedAt":"2020-04-24T16:56:50Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 24/04/2020 16:12, Đoàn Trần Công Danh wrote:\n> Somewhere later in the code, we indirectly include alloca.h\n> which will define alloca again, thus create a warning about\n> redefinition of a preprocessor.\n> \n> Include it prior to define alloca in order to not define it again.\n\nSo, on cygwin, this patch is not required. ie. I don't see any sparse\nerrors/warnings for compat/regex/regex.c.\n\nSince cygwin uses a different c library (new-lib rather than glibc),\nI did a quick test on Linux, thus:\n\n  $ sparse --version\n  v0.6.1-191-gc51a0382\n  $ \n  $ git checkout master\n  Switched to branch 'master'\n  Your branch is up-to-date with 'origin/master'.\n  $ \n  $ make clean\n  GIT_VERSION = 2.26.2.266.ge870325ee8\n  ...\n  $ \n  $ make NO_REGEX=1 sparse >sp-out1 2>&1\n  $ \n  $ diff sp-out sp-out1\n  0a1,2\n  > GIT_VERSION = 2.26.2.266.ge870325ee8\n  >     * new build flags\n  12a15\n  >     * new prefix flags\n  72a76\n  >     GEN command-list.h\n  226a231\n  >     SP compat/regex/regex.c\n  $ \n  $ make V=1 NO_REGEX=1 compat/regex/regex.sp\n  cgcc -no-compile -Werror -Wall -Wdeclaration-after-statement -Wformat-security -Wold-style-definition -Woverflow -Wpointer-arith -Wstrict-prototypes -Wunused -Wvla -DENABLE_SHA256 -Wextra -Wmissing-prototypes -Wno-empty-body -Wno-missing-field-initializers -Wno-sign-compare -Wno-unused-parameter  -g -O2 -Wall -I. -DHAVE_SYSINFO -DGIT_HOST_CPU=\"\\\"x86_64\\\"\" -DHAVE_ALLOCA_H -DUSE_CURL_FOR_IMAP_SEND -DSHA1_DC -DSHA1DC_NO_STANDARD_INCLUDES -DSHA1DC_INIT_SAFE_HASH_DEFAULT=0 -DSHA1DC_CUSTOM_INCLUDE_SHA1_C=\"\\\"cache.h\\\"\" -DSHA1DC_CUSTOM_INCLUDE_UBC_CHECK_C=\"\\\"git-compat-util.h\\\"\" -DSHA256_BLK  -DHAVE_PATHS_H -DHAVE_DEV_TTY -DHAVE_CLOCK_GETTIME -DHAVE_CLOCK_MONOTONIC -DHAVE_GETDELIM '-DPROCFS_EXECUTABLE_PATH=\"/proc/self/exe\"'  -DFREAD_READS_DIRECTORIES -DNO_STRLCPY -Icompat/regex -DSHELL_PATH='\"/bin/sh\"' -DPAGER_ENV='\"LESS=FRX LV=-c\"' -DGAWK -DNO_MBSUPPORT \\\n  \t  compat/regex/regex.c\n  $ \n   \nSo, again I don't see a problem. I guess it is possible that the\nversion of sparse I am using (see above) has _also_ fixed this\nproblem, in addition to the prototype attribute placement fix.\n\nAnother option is that the version of glibc also matters. (I am\non Linux Mint, which is based on Ubuntu 18.04 LTS) It would not\nbe the first time that I have seen errors in system header files\nchange from one release to the next ...\n\n[Hmm, I have a fedora 31 system I could try - much more up-to-date! :D ]\n\nATB,\nRamsay Jones\n\n> Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>\n> ---\n>  compat/regex/regex.c | 1 +\n>  1 file changed, 1 insertion(+)\n> \n> diff --git a/compat/regex/regex.c b/compat/regex/regex.c\n> index f3e03a9eab..4bef75a716 100644\n> --- a/compat/regex/regex.c\n> +++ b/compat/regex/regex.c\n> @@ -62,6 +62,7 @@\n>  #include <stdint.h>\n>  \n>  #ifdef GAWK\n> +#include <alloca.h>\n>  #undef alloca\n>  #define alloca alloca_is_bad_you_should_never_use_it\n>  #endif\n> \n"},{"id":"396153","messageId":"20200424170916.GA29153@danh.dev","threadId":"53297","inReplyTo":"820d44c5-5852-fa83-a814-8e58dd120565@ramsayjones.plus.com","subject":"Re: [PATCH v2 2/4] compat/regex: include alloca.h before undef it","fromName":"Danh Doan","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-04-24T17:09:16Z","receivedAt":"2020-04-24T17:09:20Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2020-04-24 17:56:46+0100, Ramsay Jones <ramsay@ramsayjones.plus.com> wrote:\n> \n> \n> On 24/04/2020 16:12, Đoàn Trần Công Danh wrote:\n> > Somewhere later in the code, we indirectly include alloca.h\n> > which will define alloca again, thus create a warning about\n> > redefinition of a preprocessor.\n> > \n> > Include it prior to define alloca in order to not define it again.\n> \n> So, on cygwin, this patch is not required. ie. I don't see any sparse\n> errors/warnings for compat/regex/regex.c.\n> \n> Since cygwin uses a different c library (new-lib rather than glibc),\n> I did a quick test on Linux, thus:\n> \n>   $ sparse --version\n>   v0.6.1-191-gc51a0382\n>   $ \n>   $ git checkout master\n>   Switched to branch 'master'\n>   Your branch is up-to-date with 'origin/master'.\n>   $ \n>   $ make clean\n>   GIT_VERSION = 2.26.2.266.ge870325ee8\n>   ...\n>   $ \n>   $ make NO_REGEX=1 sparse >sp-out1 2>&1\n>   $ \n>   $ diff sp-out sp-out1\n>   0a1,2\n>   > GIT_VERSION = 2.26.2.266.ge870325ee8\n>   >     * new build flags\n>   12a15\n>   >     * new prefix flags\n>   72a76\n>   >     GEN command-list.h\n>   226a231\n>   >     SP compat/regex/regex.c\n>   $ \n>   $ make V=1 NO_REGEX=1 compat/regex/regex.sp\n>   cgcc -no-compile -Werror -Wall -Wdeclaration-after-statement -Wformat-security -Wold-style-definition -Woverflow -Wpointer-arith -Wstrict-prototypes -Wunused -Wvla -DENABLE_SHA256 -Wextra -Wmissing-prototypes -Wno-empty-body -Wno-missing-field-initializers -Wno-sign-compare -Wno-unused-parameter  -g -O2 -Wall -I. -DHAVE_SYSINFO -DGIT_HOST_CPU=\"\\\"x86_64\\\"\" -DHAVE_ALLOCA_H -DUSE_CURL_FOR_IMAP_SEND -DSHA1_DC -DSHA1DC_NO_STANDARD_INCLUDES -DSHA1DC_INIT_SAFE_HASH_DEFAULT=0 -DSHA1DC_CUSTOM_INCLUDE_SHA1_C=\"\\\"cache.h\\\"\" -DSHA1DC_CUSTOM_INCLUDE_UBC_CHECK_C=\"\\\"git-compat-util.h\\\"\" -DSHA256_BLK  -DHAVE_PATHS_H -DHAVE_DEV_TTY -DHAVE_CLOCK_GETTIME -DHAVE_CLOCK_MONOTONIC -DHAVE_GETDELIM '-DPROCFS_EXECUTABLE_PATH=\"/proc/self/exe\"'  -DFREAD_READS_DIRECTORIES -DNO_STRLCPY -Icompat/regex -DSHELL_PATH='\"/bin/sh\"' -DPAGER_ENV='\"LESS=FRX LV=-c\"' -DGAWK -DNO_MBSUPPORT \\\n>   \t  compat/regex/regex.c\n>   $ \n>    \n> So, again I don't see a problem. I guess it is possible that the\n> version of sparse I am using (see above) has _also_ fixed this\n> problem, in addition to the prototype attribute placement fix.\n> \n> Another option is that the version of glibc also matters. (I am\n> on Linux Mint, which is based on Ubuntu 18.04 LTS) It would not\n> be the first time that I have seen errors in system header files\n> change from one release to the next ...\n\nI'm using a Linux distro with musl libc.\n\nI guess it's the main culprit?\nI have another box with glibc, but it's mostly in Windows 10,\nbecause my sister is its main user.\n\nI'll take a look if it make that warning when my sister agree to leave\nthat box to me.\n\n-- \nDanh\n"},{"id":"396168","messageId":"0bee8daa-99d0-4939-e225-8783bc0457f8@ramsayjones.plus.com","threadId":"53297","inReplyTo":"20200424170916.GA29153@danh.dev","subject":"Re: [PATCH v2 2/4] compat/regex: include alloca.h before undef it","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2020-04-24T18:29:31Z","receivedAt":"2020-04-24T18:29:36Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 24/04/2020 18:09, Danh Doan wrote:\n> On 2020-04-24 17:56:46+0100, Ramsay Jones <ramsay@ramsayjones.plus.com> wrote:\n[snip]\n\n>> So, again I don't see a problem. I guess it is possible that the\n>> version of sparse I am using (see above) has _also_ fixed this\n>> problem, in addition to the prototype attribute placement fix.\n>>\n>> Another option is that the version of glibc also matters. (I am\n>> on Linux Mint, which is based on Ubuntu 18.04 LTS) It would not\n>> be the first time that I have seen errors in system header files\n>> change from one release to the next ...\n> \n> I'm using a Linux distro with musl libc.\n\nAh, OK.\n\nI just tried re-building v0.6.1 to see if any '<alloca.h>' related\nerrors/warnings show up for me, but they don't:\n\n  $ sparse --version\n  v0.6.1\n  $ \n  $ git checkout master\n  Switched to branch 'master'\n  Your branch is up-to-date with 'origin/master'.\n  $ \n  $ make clean\n  GIT_VERSION = 2.26.2.266.ge870325ee8\n  ...\n  $ \n  $ make NO_REGEX=1 compat/regex/regex.sp\n      SP compat/regex/regex.c\n  compat/regex/regex_internal.c:925:1: error: symbol 're_string_context_at' redeclared with different type (originally declared at compat/regex/regex_internal.h:433) - different modifiers\n  $ \n\n> I guess it's the main culprit?\n\nQuite possible, I guess. What do the errors/warnings look like?\n\n> I have another box with glibc, but it's mostly in Windows 10,\n> because my sister is its main user.\n> \n> I'll take a look if it make that warning when my sister agree to leave\n> that box to me.\n\nSounds good.\n\nATB,\nRamsay Jones\n\n"},{"id":"396198","messageId":"20200424223440.GC721@danh.dev","threadId":"53297","inReplyTo":"0bee8daa-99d0-4939-e225-8783bc0457f8@ramsayjones.plus.com","subject":"Re: [PATCH v2 2/4] compat/regex: include alloca.h before undef it","fromName":"Danh Doan","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-04-24T22:34:40Z","receivedAt":"2020-04-24T22:34:45Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2020-04-24 19:29:31+0100, Ramsay Jones <ramsay@ramsayjones.plus.com> wrote:\n> \n> \n> On 24/04/2020 18:09, Danh Doan wrote:\n> > On 2020-04-24 17:56:46+0100, Ramsay Jones <ramsay@ramsayjones.plus.com> wrote:\n> [snip]\n> \n> >> So, again I don't see a problem. I guess it is possible that the\n> >> version of sparse I am using (see above) has _also_ fixed this\n> >> problem, in addition to the prototype attribute placement fix.\n> >>\n> >> Another option is that the version of glibc also matters. (I am\n> >> on Linux Mint, which is based on Ubuntu 18.04 LTS) It would not\n> >> be the first time that I have seen errors in system header files\n> >> change from one release to the next ...\n> > \n> > I'm using a Linux distro with musl libc.\n> \n> Ah, OK.\n> \n> I just tried re-building v0.6.1 to see if any '<alloca.h>' related\n> errors/warnings show up for me, but they don't:\n> \n>   $ sparse --version\n>   v0.6.1\n>   $ \n>   $ git checkout master\n>   Switched to branch 'master'\n>   Your branch is up-to-date with 'origin/master'.\n>   $ \n>   $ make clean\n>   GIT_VERSION = 2.26.2.266.ge870325ee8\n>   ...\n>   $ \n>   $ make NO_REGEX=1 compat/regex/regex.sp\n>       SP compat/regex/regex.c\n>   compat/regex/regex_internal.c:925:1: error: symbol 're_string_context_at' redeclared with different type (originally declared at compat/regex/regex_internal.h:433) - different modifiers\n>   $ \n> \n> > I guess it's the main culprit?\n> \n> Quite possible, I guess. What do the errors/warnings look like?\n\nOK, I've tried with my glibc box, it doesn't have that warning.\nOn musl, it warns:\n\n\t$ make compat/regex/regex.sp\n\tGIT_VERSION = 2.26.2\n\t    * new build flags\n\t    SP compat/regex/regex.c\n\t/usr/include/alloca.h:14:9: warning: preprocessor token alloca redefined\n\tcompat/regex/regex.c:66:9: this was the original definition\n\tcompat/regex/regex_internal.c:925:1: error: symbol 're_string_context_at' redeclared with different type (originally declared at compat/regex/regex_internal.h:433) - different modifiers\n\n\n-- \nDanh\n"},{"id":"396250","messageId":"nycvar.QRO.7.76.6.2004251511550.18039@tvgsbejvaqbjf.bet","threadId":"53297","inReplyTo":"cover.1587648870.git.congdanhqx@gmail.com","subject":"Re: [PATCH 0/4] fix make sparse warning","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2020-04-25T13:13:53Z","receivedAt":"2020-04-25T13:13:57Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Danh,\n\nOn Thu, 23 Apr 2020, Đoàn Trần Công Danh wrote:\n\n> It's happened that I tried to run make check on project that support autoconf.\n> Git's Makefile told me to run `make sparse` instead.\n>\n> I /think/ if we have a rule in Makefile, we should adhere to it.\n> I also fix another change in ds/blame-on-bloom, which I think it's worth to\n> fix, see: <20200423133937.GA1984@danh.dev>\n\nFWIW there is still an Azure Pipeline building `sparse` for Ubuntu every\ntwo weeks: https://dev.azure.com/git/git/_build?definitionId=10&_a=summary\n\nI created this Pipeline in order to support the proposed project at\nhttps://github.com/gitgitgadget/git/issues/345 which is: teach our CI\nbuilds to run `make sparse`.\n\nMaybe it is time to tackle that?\n\nCiao,\nDscho\n"},{"id":"396266","messageId":"ffcaaf4f-a43f-2d20-b70d-dfb8b1d7c687@ramsayjones.plus.com","threadId":"53297","inReplyTo":"20200424223440.GC721@danh.dev","subject":"Re: [PATCH v2 2/4] compat/regex: include alloca.h before undef it","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2020-04-25T20:28:05Z","receivedAt":"2020-04-25T20:28:12Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 24/04/2020 23:34, Danh Doan wrote:\n[snip]\n\n> OK, I've tried with my glibc box, it doesn't have that warning.\n> On musl, it warns:\n> \n> \t$ make compat/regex/regex.sp\n> \tGIT_VERSION = 2.26.2\n> \t    * new build flags\n> \t    SP compat/regex/regex.c\n> \t/usr/include/alloca.h:14:9: warning: preprocessor token alloca redefined\n> \tcompat/regex/regex.c:66:9: this was the original definition\n> \tcompat/regex/regex_internal.c:925:1: error: symbol 're_string_context_at' redeclared with different type (originally declared at compat/regex/regex_internal.h:433) - different modifiers\n> \n> \n\nOK, I had a quick look at the <alloca.h> header file on a glibc\nsystem (linux) and new-lib system (cygwin) and they both do\n(more or less) the same thing: first #undef alloca, and then\nif being compiled by gcc, define alloca(size) to be __builtin_alloca(size).\n\nSo, even if <alloca.h> is #included after regex.c:66, it wouldn't\nbe a problem. Since I don't have access to a musl based system,\nI don't know what that system header is doing.\n\nHowever, I said *even if* above, because I don't see why it is trying\nto #include <alloca.h> in the first place! ;-)\n\nNote that the three calls to alloca in compat/regex:\n\n  $ git grep -n '\\<alloca\\>' -- compat/regex\n  compat/regex/regex.c:65:#undef alloca\n  compat/regex/regex.c:66:#define alloca alloca_is_bad_you_should_never_use_it\n  compat/regex/regex_internal.h:460:#   include <alloca.h>\n  compat/regex/regex_internal.h:468:/* alloca is implemented with malloc, so just use malloc.  */\n  compat/regex/regexec.c:1428:    prev_idx_match = (regmatch_t *) alloca (nmatch * sizeof (regmatch_t));\n  compat/regex/regexec.c:3338:    dests_alloc = (struct dests_alloc *) alloca (sizeof (struct dests_alloc));\n  compat/regex/regexec.c:3385:      alloca (ndests * 3 * sizeof (re_dfastate_t *));\n  $ \n\n... in compat/regex/regexec.c are all protected by '#ifdef HAVE_ALLOCA', as\nindeed is the #include of the header file in compat/regex/regex_internal.h\nat line 460. Since HAVE_ALLOCA should not be defined, where is that file\nbeing included?\n\nNote that HAVE_ALLOCA\n \n  $ git grep -n HAVE_ALLOCA -- compat\n  compat/regex/regex_internal.h:455:# if HAVE_ALLOCA\n  compat/regex/regexec.c:1426:#ifdef HAVE_ALLOCA\n  compat/regex/regexec.c:3336:#ifdef HAVE_ALLOCA\n  compat/regex/regexec.c:3381:#ifdef HAVE_ALLOCA\n  $ \n\n... is not the same as HAVE_ALLOCA_H\n\n  $ git grep -n HAVE_ALLOCA\n  Makefile:45:# Define HAVE_ALLOCA_H if you have working alloca(3) defined in that header.\n  Makefile:1349:ifdef HAVE_ALLOCA_H\n  Makefile:1350:  BASIC_CFLAGS += -DHAVE_ALLOCA_H\n  compat/regex/regex_internal.h:455:# if HAVE_ALLOCA\n  compat/regex/regexec.c:1426:#ifdef HAVE_ALLOCA\n  compat/regex/regexec.c:3336:#ifdef HAVE_ALLOCA\n  compat/regex/regexec.c:3381:#ifdef HAVE_ALLOCA\n  config.mak.uname:47:    HAVE_ALLOCA_H = YesPlease\n  config.mak.uname:63:    HAVE_ALLOCA_H = YesPlease\n  config.mak.uname:147:   HAVE_ALLOCA_H = YesPlease\n  config.mak.uname:206:   HAVE_ALLOCA_H = YesPlease\n  config.mak.uname:310:   HAVE_ALLOCA_H = YesPlease\n  config.mak.uname:395:   HAVE_ALLOCA_H = YesPlease\n  config.mak.uname:586:   HAVE_ALLOCA_H = YesPlease\n  configure.ac:320:# Define HAVE_ALLOCA_H if you have working alloca(3) defined in that header.\n  configure.ac:323:    yes)    HAVE_ALLOCA_H=YesPlease;;\n  configure.ac:324:    *)      HAVE_ALLOCA_H='';;\n  configure.ac:326:GIT_CONF_SUBST([HAVE_ALLOCA_H])\n  git-compat-util.h:840:#ifdef HAVE_ALLOCA_H\n  $ \n\n... used by the rest of git, outside of the compat/regex directory.\n\nOnce again, you can see that HAVE_ALLOCA\n\n  $ make V=1 NO_REGEX=1 compat/regex/regex.sp\n  cgcc -no-compile -Werror -Wall -Wdeclaration-after-statement -Wformat-security -Wold-style-definition -Woverflow -Wpointer-arith -Wstrict-prototypes -Wunused -Wvla -DENABLE_SHA256 -Wextra -Wmissing-prototypes -Wno-empty-body -Wno-missing-field-initializers -Wno-sign-compare -Wno-unused-parameter  -g -O2 -Wall -I. -DHAVE_SYSINFO -DGIT_HOST_CPU=\"\\\"x86_64\\\"\" -DHAVE_ALLOCA_H  -DUSE_CURL_FOR_IMAP_SEND -DSHA1_DC -DSHA1DC_NO_STANDARD_INCLUDES -DSHA1DC_INIT_SAFE_HASH_DEFAULT=0 -DSHA1DC_CUSTOM_INCLUDE_SHA1_C=\"\\\"cache.h\\\"\" -DSHA1DC_CUSTOM_INCLUDE_UBC_CHECK_C=\"\\\"git-compat-util.h\\\"\" -DSHA256_BLK  -DHAVE_PATHS_H -DHAVE_DEV_TTY -DHAVE_CLOCK_GETTIME -DHAVE_CLOCK_MONOTONIC -DHAVE_GETDELIM '-DPROCFS_EXECUTABLE_PATH=\"/proc/self/exe\"'  -DFREAD_READS_DIRECTORIES -DNO_STRLCPY -Icompat/regex -DSHELL_PATH='\"/bin/sh\"' -DPAGER_ENV='\"LESS=FRX LV=-c\"' -DGAWK -DNO_MBSUPPORT \\\n  \t  compat/regex/regex.c\n  $ \n  \n... is not being set on the command-line.\n\nHmm, do you have this set in config.mak, config.mak.autogen, or some other\nsource? puzzled! ;-)\n\nBTW, why are you compiling with NO_REGEX set anyway?\n\n\nATB,\nRamsay Jones\n\n"},{"id":"396277","messageId":"20200426005451.f7pyoiijgbk4hpsj@danh.dev","threadId":"53297","inReplyTo":"ffcaaf4f-a43f-2d20-b70d-dfb8b1d7c687@ramsayjones.plus.com","subject":"Re: [PATCH v2 2/4] compat/regex: include alloca.h before undef it","fromName":"Danh Doan","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-04-26T00:54:51Z","receivedAt":"2020-04-26T00:55:11Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2020-04-25 21:28:05+0100, Ramsay Jones <ramsay@ramsayjones.plus.com> wrote:\n> \n> \n> On 24/04/2020 23:34, Danh Doan wrote:\n> [snip]\n> \n> > OK, I've tried with my glibc box, it doesn't have that warning.\n> > On musl, it warns:\n> > \n> > \t$ make compat/regex/regex.sp\n> > \tGIT_VERSION = 2.26.2\n> > \t    * new build flags\n> > \t    SP compat/regex/regex.c\n> > \t/usr/include/alloca.h:14:9: warning: preprocessor token alloca redefined\n> > \tcompat/regex/regex.c:66:9: this was the original definition\n> > \tcompat/regex/regex_internal.c:925:1: error: symbol 're_string_context_at' redeclared with different type (originally declared at compat/regex/regex_internal.h:433) - different modifiers\n> > \n> > \n> \n> OK, I had a quick look at the <alloca.h> header file on a glibc\n> system (linux) and new-lib system (cygwin) and they both do\n> (more or less) the same thing: first #undef alloca, and then\n> if being compiled by gcc, define alloca(size) to be __builtin_alloca(size).\n\nmusl people don't do that.\nThey just go ahead define it, if any other header file requires\nalloca, they will include alloca.h\n\n> So, even if <alloca.h> is #included after regex.c:66, it wouldn't\n> be a problem. Since I don't have access to a musl based system,\n> I don't know what that system header is doing.\n\nmusl's alloca.h is available here:\n\nhttps://git.musl-libc.org/cgit/musl/tree/include/alloca.h\n\n> However, I said *even if* above, because I don't see why it is trying\n> to #include <alloca.h> in the first place! ;-)\n\nI looked into my system again. The inclusion chain is:\n\ncompat/regex/regex.c:77\n`-> compat/regex/regex_internal.h:26\n    `-> /usr/include/stdlib.h:138 [*1*]\n\n[*1*]: https://git.musl-libc.org/cgit/musl/tree/include/stdlib.h#n137\n\nI don't know why _GNU_SOURCE and/or _BSD_SOURCE is defined.\n\n>   $ make V=1 NO_REGEX=1 compat/regex/regex.sp\n>   cgcc -no-compile -Werror -Wall -Wdeclaration-after-statement -Wformat-security -Wold-style-definition -Woverflow -Wpointer-arith -Wstrict-prototypes -Wunused -Wvla -DENABLE_SHA256 -Wextra -Wmissing-prototypes -Wno-empty-body -Wno-missing-field-initializers -Wno-sign-compare -Wno-unused-parameter  -g -O2 -Wall -I. -DHAVE_SYSINFO -DGIT_HOST_CPU=\"\\\"x86_64\\\"\" -DHAVE_ALLOCA_H  -DUSE_CURL_FOR_IMAP_SEND -DSHA1_DC -DSHA1DC_NO_STANDARD_INCLUDES -DSHA1DC_INIT_SAFE_HASH_DEFAULT=0 -DSHA1DC_CUSTOM_INCLUDE_SHA1_C=\"\\\"cache.h\\\"\" -DSHA1DC_CUSTOM_INCLUDE_UBC_CHECK_C=\"\\\"git-compat-util.h\\\"\" -DSHA256_BLK  -DHAVE_PATHS_H -DHAVE_DEV_TTY -DHAVE_CLOCK_GETTIME -DHAVE_CLOCK_MONOTONIC -DHAVE_GETDELIM '-DPROCFS_EXECUTABLE_PATH=\"/proc/self/exe\"'  -DFREAD_READS_DIRECTORIES -DNO_STRLCPY -Icompat/regex -DSHELL_PATH='\"/bin/sh\"' -DPAGER_ENV='\"LESS=FRX LV=-c\"' -DGAWK -DNO_MBSUPPORT \\\n>   \t  compat/regex/regex.c\n>   $ \n>   \n> ... is not being set on the command-line.\n\nHere's the invocation of cc and cgcc:\n\n\t$ make V=1  compat/regex/regex.o\n\tcc -o compat/regex/regex.o -c -MF compat/regex/.depend/regex.o.d -MQ compat/regex/regex.o -MMD -MP -Werror -Wall -Wdeclaration-after-statement -Wformat-security -Wold-style-definition -Woverflow -Wpointer-arith -Wstrict-prototypes -Wunused -Wvla -DENABLE_SHA256 -Wextra -Wmissing-prototypes -Wno-empty-body -Wno-missing-field-initializers -Wno-sign-compare -Wno-unused-parameter  -g -O2 -Wall -I. -DHAVE_SYSINFO -DGIT_HOST_CPU=\"\\\"x86_64\\\"\" -DUSE_LIBPCRE2 -DHAVE_ALLOCA_H -DUSE_CURL_FOR_IMAP_SEND -DICONV_OMITS_BOM -DSHA1_DC -DSHA1DC_NO_STANDARD_INCLUDES -DSHA1DC_INIT_SAFE_HASH_DEFAULT=0 -DSHA1DC_CUSTOM_INCLUDE_SHA1_C=\"\\\"cache.h\\\"\" -DSHA1DC_CUSTOM_INCLUDE_UBC_CHECK_C=\"\\\"git-compat-util.h\\\"\" -DSHA256_BLK  -DHAVE_PATHS_H -DHAVE_DEV_TTY -DHAVE_CLOCK_GETTIME -DHAVE_CLOCK_MONOTONIC -DHAVE_GETDELIM '-DPROCFS_EXECUTABLE_PATH=\"/proc/self/exe\"' -DFREAD_READS_DIRECTORIES -DNO_STRLCPY -Icompat/regex -DSHELL_PATH='\"/bin/sh\"' -DPAGER_ENV='\"LESS=FRX LV=-c\"' -DGAWK -DNO_MBSUPPORT compat/regex/regex.c\n\t$ make V=1  compat/regex/regex.sp\n\tcgcc -no-compile -Werror -Wall -Wdeclaration-after-statement -Wformat-security -Wold-style-definition -Woverflow -Wpointer-arith -Wstrict-prototypes -Wunused -Wvla -DENABLE_SHA256 -Wextra -Wmissing-prototypes -Wno-empty-body -Wno-missing-field-initializers -Wno-sign-compare -Wno-unused-parameter  -g -O2 -Wall -I. -DHAVE_SYSINFO -DGIT_HOST_CPU=\"\\\"x86_64\\\"\" -DUSE_LIBPCRE2 -DHAVE_ALLOCA_H -DUSE_CURL_FOR_IMAP_SEND -DICONV_OMITS_BOM -DSHA1_DC -DSHA1DC_NO_STANDARD_INCLUDES -DSHA1DC_INIT_SAFE_HASH_DEFAULT=0 -DSHA1DC_CUSTOM_INCLUDE_SHA1_C=\"\\\"cache.h\\\"\" -DSHA1DC_CUSTOM_INCLUDE_UBC_CHECK_C=\"\\\"git-compat-util.h\\\"\" -DSHA256_BLK  -DHAVE_PATHS_H -DHAVE_DEV_TTY -DHAVE_CLOCK_GETTIME -DHAVE_CLOCK_MONOTONIC -DHAVE_GETDELIM '-DPROCFS_EXECUTABLE_PATH=\"/proc/self/exe\"' -DFREAD_READS_DIRECTORIES -DNO_STRLCPY -Icompat/regex -DSHELL_PATH='\"/bin/sh\"' -DPAGER_ENV='\"LESS=FRX LV=-c\"' -DGAWK -DNO_MBSUPPORT \\\n\t          compat/regex/regex.c\n\n> Hmm, do you have this set in config.mak, config.mak.autogen, or some other\n> source? puzzled! ;-)\n\nI don't have `config.make.autogen`,\nHere is config.mak\n\n\t$ cat config.mak\n\tUSE_ASCIIDOCTOR=Yes\n\tDEVELOPER=1\n\tDEFAULT_TEST_TARGET=prove\n\tprefix = /home/danh/.local\n\tUSE_LIBPCRE2=YesPlease\n\tICONV_OMITS_BOM=Yes\n\tNO_REGEX=YesPlease\n\n> BTW, why are you compiling with NO_REGEX set anyway?\n\nBecause I use musl-libc, and musl-libc doesn't have StartEnd\n\n-- \nDanh\n"},{"id":"396278","messageId":"20200426011013.4dheltp2rumn3bad@danh.dev","threadId":"53297","inReplyTo":"20200426005451.f7pyoiijgbk4hpsj@danh.dev","subject":"Re: [PATCH v2 2/4] compat/regex: include alloca.h before undef it","fromName":"Danh Doan","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-04-26T01:10:13Z","receivedAt":"2020-04-26T01:10:18Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2020-04-26 07:54:51+0700, Danh Doan <congdanhqx@gmail.com> wrote:\n> On 2020-04-25 21:28:05+0100, Ramsay Jones <ramsay@ramsayjones.plus.com> wrote:\n> > \n> > \n> > On 24/04/2020 23:34, Danh Doan wrote:\n> > [snip]\n> > \n> > > OK, I've tried with my glibc box, it doesn't have that warning.\n> > > On musl, it warns:\n> > > \n> > > \t$ make compat/regex/regex.sp\n> > > \tGIT_VERSION = 2.26.2\n> > > \t    * new build flags\n> > > \t    SP compat/regex/regex.c\n> > > \t/usr/include/alloca.h:14:9: warning: preprocessor token alloca redefined\n> > > \tcompat/regex/regex.c:66:9: this was the original definition\n> > > \tcompat/regex/regex_internal.c:925:1: error: symbol 're_string_context_at' redeclared with different type (originally declared at compat/regex/regex_internal.h:433) - different modifiers\n> > > \n> > > \n> > \n> > OK, I had a quick look at the <alloca.h> header file on a glibc\n> > system (linux) and new-lib system (cygwin) and they both do\n> > (more or less) the same thing: first #undef alloca, and then\n> > if being compiled by gcc, define alloca(size) to be __builtin_alloca(size).\n> \n> musl people don't do that.\n> They just go ahead define it, if any other header file requires\n> alloca, they will include alloca.h\n> \n> > So, even if <alloca.h> is #included after regex.c:66, it wouldn't\n> > be a problem. Since I don't have access to a musl based system,\n> > I don't know what that system header is doing.\n> \n> musl's alloca.h is available here:\n> \n> https://git.musl-libc.org/cgit/musl/tree/include/alloca.h\n> \n> > However, I said *even if* above, because I don't see why it is trying\n> > to #include <alloca.h> in the first place! ;-)\n> \n> I looked into my system again. The inclusion chain is:\n> \n> compat/regex/regex.c:77\n> `-> compat/regex/regex_internal.h:26\n>     `-> /usr/include/stdlib.h:138 [*1*]\n>         `-> /usr/include/alloca.h\n> \n> [*1*]: https://git.musl-libc.org/cgit/musl/tree/include/stdlib.h#n137\n\nSorry for the noise, but I should link to a specific tree instead of\ntheir master for future refererence.\n\nhttps://git.musl-libc.org/cgit/musl/tree/include/stdlib.h?id=8e452abae67db445fb6c3e37cd566c4788c2e8f3#n137\n\n> \n> I don't know why _GNU_SOURCE and/or _BSD_SOURCE is defined.\n> \n> >   $ make V=1 NO_REGEX=1 compat/regex/regex.sp\n> >   cgcc -no-compile -Werror -Wall -Wdeclaration-after-statement -Wformat-security -Wold-style-definition -Woverflow -Wpointer-arith -Wstrict-prototypes -Wunused -Wvla -DENABLE_SHA256 -Wextra -Wmissing-prototypes -Wno-empty-body -Wno-missing-field-initializers -Wno-sign-compare -Wno-unused-parameter  -g -O2 -Wall -I. -DHAVE_SYSINFO -DGIT_HOST_CPU=\"\\\"x86_64\\\"\" -DHAVE_ALLOCA_H  -DUSE_CURL_FOR_IMAP_SEND -DSHA1_DC -DSHA1DC_NO_STANDARD_INCLUDES -DSHA1DC_INIT_SAFE_HASH_DEFAULT=0 -DSHA1DC_CUSTOM_INCLUDE_SHA1_C=\"\\\"cache.h\\\"\" -DSHA1DC_CUSTOM_INCLUDE_UBC_CHECK_C=\"\\\"git-compat-util.h\\\"\" -DSHA256_BLK  -DHAVE_PATHS_H -DHAVE_DEV_TTY -DHAVE_CLOCK_GETTIME -DHAVE_CLOCK_MONOTONIC -DHAVE_GETDELIM '-DPROCFS_EXECUTABLE_PATH=\"/proc/self/exe\"'  -DFREAD_READS_DIRECTORIES -DNO_STRLCPY -Icompat/regex -DSHELL_PATH='\"/bin/sh\"' -DPAGER_ENV='\"LESS=FRX LV=-c\"' -DGAWK -DNO_MBSUPPORT \\\n> >   \t  compat/regex/regex.c\n> >   $ \n> >   \n> > ... is not being set on the command-line.\n> \n> Here's the invocation of cc and cgcc:\n> \n> \t$ make V=1  compat/regex/regex.o\n> \tcc -o compat/regex/regex.o -c -MF compat/regex/.depend/regex.o.d -MQ compat/regex/regex.o -MMD -MP -Werror -Wall -Wdeclaration-after-statement -Wformat-security -Wold-style-definition -Woverflow -Wpointer-arith -Wstrict-prototypes -Wunused -Wvla -DENABLE_SHA256 -Wextra -Wmissing-prototypes -Wno-empty-body -Wno-missing-field-initializers -Wno-sign-compare -Wno-unused-parameter  -g -O2 -Wall -I. -DHAVE_SYSINFO -DGIT_HOST_CPU=\"\\\"x86_64\\\"\" -DUSE_LIBPCRE2 -DHAVE_ALLOCA_H -DUSE_CURL_FOR_IMAP_SEND -DICONV_OMITS_BOM -DSHA1_DC -DSHA1DC_NO_STANDARD_INCLUDES -DSHA1DC_INIT_SAFE_HASH_DEFAULT=0 -DSHA1DC_CUSTOM_INCLUDE_SHA1_C=\"\\\"cache.h\\\"\" -DSHA1DC_CUSTOM_INCLUDE_UBC_CHECK_C=\"\\\"git-compat-util.h\\\"\" -DSHA256_BLK  -DHAVE_PATHS_H -DHAVE_DEV_TTY -DHAVE_CLOCK_GETTIME -DHAVE_CLOCK_MONOTONIC -DHAVE_GETDELIM '-DPROCFS_EXECUTABLE_PATH=\"/proc/self/exe\"' -DFREAD_READS_DIRECTORIES -DNO_STRLCPY -Icompat/regex -DSHELL_PATH='\"/bin/sh\"' -DPAGER_ENV='\"LESS=FRX LV=-c\"' -DGAWK -DNO_MBSUPPORT compat/regex/regex.c\n> \t$ make V=1  compat/regex/regex.sp\n> \tcgcc -no-compile -Werror -Wall -Wdeclaration-after-statement -Wformat-security -Wold-style-definition -Woverflow -Wpointer-arith -Wstrict-prototypes -Wunused -Wvla -DENABLE_SHA256 -Wextra -Wmissing-prototypes -Wno-empty-body -Wno-missing-field-initializers -Wno-sign-compare -Wno-unused-parameter  -g -O2 -Wall -I. -DHAVE_SYSINFO -DGIT_HOST_CPU=\"\\\"x86_64\\\"\" -DUSE_LIBPCRE2 -DHAVE_ALLOCA_H -DUSE_CURL_FOR_IMAP_SEND -DICONV_OMITS_BOM -DSHA1_DC -DSHA1DC_NO_STANDARD_INCLUDES -DSHA1DC_INIT_SAFE_HASH_DEFAULT=0 -DSHA1DC_CUSTOM_INCLUDE_SHA1_C=\"\\\"cache.h\\\"\" -DSHA1DC_CUSTOM_INCLUDE_UBC_CHECK_C=\"\\\"git-compat-util.h\\\"\" -DSHA256_BLK  -DHAVE_PATHS_H -DHAVE_DEV_TTY -DHAVE_CLOCK_GETTIME -DHAVE_CLOCK_MONOTONIC -DHAVE_GETDELIM '-DPROCFS_EXECUTABLE_PATH=\"/proc/self/exe\"' -DFREAD_READS_DIRECTORIES -DNO_STRLCPY -Icompat/regex -DSHELL_PATH='\"/bin/sh\"' -DPAGER_ENV='\"LESS=FRX LV=-c\"' -DGAWK -DNO_MBSUPPORT \\\n> \t          compat/regex/regex.c\n> \n> > Hmm, do you have this set in config.mak, config.mak.autogen, or some other\n> > source? puzzled! ;-)\n> \n> I don't have `config.make.autogen`,\n> Here is config.mak\n> \n> \t$ cat config.mak\n> \tUSE_ASCIIDOCTOR=Yes\n> \tDEVELOPER=1\n> \tDEFAULT_TEST_TARGET=prove\n> \tprefix = /home/danh/.local\n> \tUSE_LIBPCRE2=YesPlease\n> \tICONV_OMITS_BOM=Yes\n> \tNO_REGEX=YesPlease\n> \n> > BTW, why are you compiling with NO_REGEX set anyway?\n> \n> Because I use musl-libc, and musl-libc doesn't have StartEnd\n> \n> -- \n> Danh\n\n-- \nDanh\n"},{"id":"396282","messageId":"20200426033201.GA14800@danh.dev","threadId":"53297","inReplyTo":"nycvar.QRO.7.76.6.2004251511550.18039@tvgsbejvaqbjf.bet","subject":"Re: [PATCH 0/4] fix make sparse warning","fromName":"Danh Doan","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-04-26T03:32:01Z","receivedAt":"2020-04-26T03:32:08Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2020-04-25 15:13:53+0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> Hi Danh,\n> \n> On Thu, 23 Apr 2020, Đoàn Trần Công Danh wrote:\n> \n> > It's happened that I tried to run make check on project that support autoconf.\n> > Git's Makefile told me to run `make sparse` instead.\n> >\n> > I /think/ if we have a rule in Makefile, we should adhere to it.\n> > I also fix another change in ds/blame-on-bloom, which I think it's worth to\n> > fix, see: <20200423133937.GA1984@danh.dev>\n> \n> FWIW there is still an Azure Pipeline building `sparse` for Ubuntu every\n> two weeks: https://dev.azure.com/git/git/_build?definitionId=10&_a=summary\n> \n> I created this Pipeline in order to support the proposed project at\n> https://github.com/gitgitgadget/git/issues/345 which is: teach our CI\n> builds to run `make sparse`.\n> \n> Maybe it is time to tackle that?\n\nI don't think it's ready, yet!\n\nMay be it's.\n\nBut we'll need\n\n\tmake sparse |\n\tgrep -v -e 'plain integer as NULL pointer' \\\n\t\t-e 'redeclared with different type'\n\nThe first one for:\n\n\tstruct foo val = { 0 };\n\nto zero structure.\n\nThe second one for different in declaration and definition (which is\nfixed in sparse's master).\n\n\n-- \nDanh\n"},{"id":"396289","messageId":"e9163e0d-2572-e7e0-6aa3-09ce04750b22@ramsayjones.plus.com","threadId":"53297","inReplyTo":"20200426005451.f7pyoiijgbk4hpsj@danh.dev","subject":"Re: [PATCH v2 2/4] compat/regex: include alloca.h before undef it","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2020-04-26T16:17:56Z","receivedAt":"2020-04-26T16:18:03Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 26/04/2020 01:54, Danh Doan wrote:\n> On 2020-04-25 21:28:05+0100, Ramsay Jones <ramsay@ramsayjones.plus.com> wrote:\n[snip]\n>> OK, I had a quick look at the <alloca.h> header file on a glibc\n>> system (linux) and new-lib system (cygwin) and they both do\n>> (more or less) the same thing: first #undef alloca, and then\n>> if being compiled by gcc, define alloca(size) to be __builtin_alloca(size).\n> \n> musl people don't do that.\n> They just go ahead define it, if any other header file requires\n> alloca, they will include alloca.h\n> \n>> So, even if <alloca.h> is #included after regex.c:66, it wouldn't\n>> be a problem. Since I don't have access to a musl based system,\n>> I don't know what that system header is doing.\n> \n> musl's alloca.h is available here:\n> \n> https://git.musl-libc.org/cgit/musl/tree/include/alloca.h\n\nHmm, OK, so that partly explains the problem. I wonder if the\nmusl guys would accept a bug report?\n\n>> However, I said *even if* above, because I don't see why it is trying\n>> to #include <alloca.h> in the first place! ;-)\n> \n> I looked into my system again. The inclusion chain is:\n> \n> compat/regex/regex.c:77\n> `-> compat/regex/regex_internal.h:26\n>     `-> /usr/include/stdlib.h:138 [*1*]\n> \n> [*1*]: https://git.musl-libc.org/cgit/musl/tree/include/stdlib.h#n137\n> \n> I don't know why _GNU_SOURCE and/or _BSD_SOURCE is defined.\n\n... and this explains the main cause. Hmm, as you say, why are\none (or both) of those pp variables set. :(\n\n[snip] \n>> BTW, why are you compiling with NO_REGEX set anyway?\n> \n> Because I use musl-libc, and musl-libc doesn't have StartEnd\n\nAh, OK. ;-)\n\nWell, even if the musl project accepted a PR and provided a fix, that\nwill not help you in the short term! :D\n\nHmm, whatever patch you decide to send (even the original one) I think\nyou need to add an explanation of the problem to the commit message,\nincluding why the patch provides a solution. (You don't have to type\na novel - see commit bd8f005583 :-P ).\n\nI haven't thought about this too much, but some options:\n\n  - iff the musl library sets some kind of identifying pp variable\n    (_MUSL_LIBC_ or somesuch - I haven't looked), then you could\n    make the '#include <alloca.h>' conditional on that variable.\n    This has the benefit of making it obvious to people reading the\n    code that this is specific to musl-libc.\n\n  - you could simply remove that '#ifdef GAWK' block completely (Lines\n    64->67). We set GAWK and NO_MBSUPPORT  unconditionally in the Makefile\n    so that it compiles (see commit a997bf423d), but these particular\n    lines simply reflect the gawk projects dislike of alloca (along with\n    the desire to catch any attempts to add new calls which are not protected\n    by HAVE_ALLOCA). Given that we are very unlikely to add new calls ...\n\n  - change the conditional on this block to (totally untested, just typing\n    into my email client) '#if defined(GAWK) && defined(HAVE_ALLOCA)'.\n    This should work, but it does disable the 'catch any attempts to add\n    new _unintentional_ calls' aspect of that block; so you may as well\n    remove it ...\n\nJust some 'off the top of my head ideas', ... ;-)\n\nATB,\nRamsay Jones\n\n\n"},{"id":"396290","messageId":"45522b6a-76a4-a7d9-3cce-a3581aaca899@ramsayjones.plus.com","threadId":"53297","inReplyTo":"20200426033201.GA14800@danh.dev","subject":"Re: [PATCH 0/4] fix make sparse warning","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2020-04-26T16:24:57Z","receivedAt":"2020-04-26T16:25:05Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 26/04/2020 04:32, Danh Doan wrote:\n> On 2020-04-25 15:13:53+0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n>> Hi Danh,\n>>\n>> On Thu, 23 Apr 2020, Đoàn Trần Công Danh wrote:\n>>\n>>> It's happened that I tried to run make check on project that support autoconf.\n>>> Git's Makefile told me to run `make sparse` instead.\n>>>\n>>> I /think/ if we have a rule in Makefile, we should adhere to it.\n>>> I also fix another change in ds/blame-on-bloom, which I think it's worth to\n>>> fix, see: <20200423133937.GA1984@danh.dev>\n>>\n>> FWIW there is still an Azure Pipeline building `sparse` for Ubuntu every\n>> two weeks: https://dev.azure.com/git/git/_build?definitionId=10&_a=summary\n>>\n>> I created this Pipeline in order to support the proposed project at\n>> https://github.com/gitgitgadget/git/issues/345 which is: teach our CI\n>> builds to run `make sparse`.\n>>\n>> Maybe it is time to tackle that?\n> \n> I don't think it's ready, yet!\n\nHeh, not too long ago, the 'master' and 'next' branches were 'sparse clean'.\n(on non NO_REGEX builds anyway, and even on those for some of us. ;-) )\nThe 'pu' branch was frequently 'unclean', of course.\n\nATB,\nRamsay Jones\n\n> \n> May be it's.\n> \n> But we'll need\n> \n> \tmake sparse |\n> \tgrep -v -e 'plain integer as NULL pointer' \\\n> \t\t-e 'redeclared with different type'\n> \n> The first one for:\n> \n> \tstruct foo val = { 0 };\n> \n> to zero structure.\n> \n> The second one for different in declaration and definition (which is\n> fixed in sparse's master).\n> \n> \n"},{"id":"396298","messageId":"1a0c2b25-e283-9936-1fa2-ce51df1404dc@ramsayjones.plus.com","threadId":"53297","inReplyTo":"e9163e0d-2572-e7e0-6aa3-09ce04750b22@ramsayjones.plus.com","subject":"Re: [PATCH v2 2/4] compat/regex: include alloca.h before undef it","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2020-04-26T19:38:26Z","receivedAt":"2020-04-26T19:38:31Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 26/04/2020 17:17, Ramsay Jones wrote:\n[snip]\n\n> Hmm, whatever patch you decide to send (even the original one) I think\n> you need to add an explanation of the problem to the commit message,\n> including why the patch provides a solution. (You don't have to type\n> a novel - see commit bd8f005583 :-P ).\n> \n> I haven't thought about this too much, but some options:\n> \n>   - iff the musl library sets some kind of identifying pp variable\n>     (_MUSL_LIBC_ or somesuch - I haven't looked), then you could\n>     make the '#include <alloca.h>' conditional on that variable.\n>     This has the benefit of making it obvious to people reading the\n>     code that this is specific to musl-libc.\n> \n>   - you could simply remove that '#ifdef GAWK' block completely (Lines\n>     64->67). We set GAWK and NO_MBSUPPORT  unconditionally in the Makefile\n>     so that it compiles (see commit a997bf423d), but these particular\n>     lines simply reflect the gawk projects dislike of alloca (along with\n>     the desire to catch any attempts to add new calls which are not protected\n>     by HAVE_ALLOCA). Given that we are very unlikely to add new calls ...\n> \n>   - change the conditional on this block to (totally untested, just typing\n>     into my email client) '#if defined(GAWK) && defined(HAVE_ALLOCA)'.\n>     This should work, but it does disable the 'catch any attempts to add\n>     new _unintentional_ calls' aspect of that block; so you may as well\n>     remove it ...\n> \n> Just some 'off the top of my head ideas', ... ;-)\n\nAnother option I thought about, but didn't mention above, is given by\nthe patch below. I didn't mention it because it has the potential to\ncause problems on non musl-libc systems (and I was feeling too lazy at\nthe time to go and test ...). Again, see commit bd8f005583.\n\nSo, I have now tested this patch on (glibc) linux and it seems to work\njust fine; compile, sparse, test-suite passed. It also compiles clean\n(and sparse clean) on cygwin (new-lib) - I didn't run the test-suite\non cygwin, since it takes about 3.5 to 4 hours to run.\n\nI don't have any other systems to test this on, so I can't say that it\nwon't cause problems somewhere. In practice, I think the chances of that\nare rather low, but don't quote me on that! :-P\n\nATB,\nRamsay Jones\n\n-- >8 --\nSubject: [PATCH] regex: fix up musl-libc builds\n\n---\n compat/regex/regex.c          | 1 +\n compat/regex/regex_internal.h | 1 -\n 2 files changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/compat/regex/regex.c b/compat/regex/regex.c\nindex f3e03a9eab..e6f4a5d177 100644\n--- a/compat/regex/regex.c\n+++ b/compat/regex/regex.c\n@@ -60,6 +60,7 @@\n    #undefs RE_DUP_MAX and sets it to the right value.  */\n #include <limits.h>\n #include <stdint.h>\n+#include <stdlib.h>\n \n #ifdef GAWK\n #undef alloca\ndiff --git a/compat/regex/regex_internal.h b/compat/regex/regex_internal.h\nindex 3ee8aae59d..0bad8b841e 100644\n--- a/compat/regex/regex_internal.h\n+++ b/compat/regex/regex_internal.h\n@@ -23,7 +23,6 @@\n #include <assert.h>\n #include <ctype.h>\n #include <stdio.h>\n-#include <stdlib.h>\n #include <string.h>\n \n #if defined HAVE_LANGINFO_H || defined HAVE_LANGINFO_CODESET || defined _LIBC\n-- \n2.26.2\n\n"},{"id":"396306","messageId":"xmqqo8rd98mn.fsf@gitster.c.googlers.com","threadId":"53297","inReplyTo":"1a0c2b25-e283-9936-1fa2-ce51df1404dc@ramsayjones.plus.com","subject":"Re: [PATCH v2 2/4] compat/regex: include alloca.h before undef it","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-04-26T22:37:04Z","receivedAt":"2020-04-26T22:37:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramsay Jones <ramsay@ramsayjones.plus.com> writes:\n\n> I don't have any other systems to test this on, so I can't say that it\n> won't cause problems somewhere. In practice, I think the chances of that\n> are rather low, but don't quote me on that! :-P\n\nThis does smell like a right approach to me.  If we can get it\ntested widely, that would be good.\n\nThanks.\n\n> -- >8 --\n> Subject: [PATCH] regex: fix up musl-libc builds\n>\n> ---\n>  compat/regex/regex.c          | 1 +\n>  compat/regex/regex_internal.h | 1 -\n>  2 files changed, 1 insertion(+), 1 deletion(-)\n>\n> diff --git a/compat/regex/regex.c b/compat/regex/regex.c\n> index f3e03a9eab..e6f4a5d177 100644\n> --- a/compat/regex/regex.c\n> +++ b/compat/regex/regex.c\n> @@ -60,6 +60,7 @@\n>     #undefs RE_DUP_MAX and sets it to the right value.  */\n>  #include <limits.h>\n>  #include <stdint.h>\n> +#include <stdlib.h>\n>  \n>  #ifdef GAWK\n>  #undef alloca\n> diff --git a/compat/regex/regex_internal.h b/compat/regex/regex_internal.h\n> index 3ee8aae59d..0bad8b841e 100644\n> --- a/compat/regex/regex_internal.h\n> +++ b/compat/regex/regex_internal.h\n> @@ -23,7 +23,6 @@\n>  #include <assert.h>\n>  #include <ctype.h>\n>  #include <stdio.h>\n> -#include <stdlib.h>\n>  #include <string.h>\n>  \n>  #if defined HAVE_LANGINFO_H || defined HAVE_LANGINFO_CODESET || defined _LIBC\n"},{"id":"396312","messageId":"20200427010821.GD14800@danh.dev","threadId":"53297","inReplyTo":"e9163e0d-2572-e7e0-6aa3-09ce04750b22@ramsayjones.plus.com","subject":"Re: [PATCH v2 2/4] compat/regex: include alloca.h before undef it","fromName":"Danh Doan","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-04-27T01:08:21Z","receivedAt":"2020-04-27T01:08:26Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2020-04-26 17:17:56+0100, Ramsay Jones <ramsay@ramsayjones.plus.com> wrote:\n> \n> \n> On 26/04/2020 01:54, Danh Doan wrote:\n> > On 2020-04-25 21:28:05+0100, Ramsay Jones <ramsay@ramsayjones.plus.com> wrote:\n> [snip]\n> >> OK, I had a quick look at the <alloca.h> header file on a glibc\n> >> system (linux) and new-lib system (cygwin) and they both do\n> >> (more or less) the same thing: first #undef alloca, and then\n> >> if being compiled by gcc, define alloca(size) to be __builtin_alloca(size).\n> > \n> > musl people don't do that.\n> > They just go ahead define it, if any other header file requires\n> > alloca, they will include alloca.h\n> > \n> >> So, even if <alloca.h> is #included after regex.c:66, it wouldn't\n> >> be a problem. Since I don't have access to a musl based system,\n> >> I don't know what that system header is doing.\n> > \n> > musl's alloca.h is available here:\n> > \n> > https://git.musl-libc.org/cgit/musl/tree/include/alloca.h\n> \n> Hmm, OK, so that partly explains the problem. I wonder if the\n> musl guys would accept a bug report?\n\nI don't think they have a policy of no `#undef` whatsoever.\nBut, I think they're picky when come to C-correctly and\nPOSIX-correctly.\nDoes C or POSIX define alloca(3) at all?\n\nAnd, I /think/ they'll likely ignore this one, [musl-faq] says:\n\n\tAssuming that including one header will cause symbols from\n\tanother unrelated header to be exposed. This is an application\n\tbug, and fixing it is as simple as adding the missing #include\n\tdirectives. \n\nI guess they meant, if we have `alloca` defined, we must have included\n`alloca.h` somewhere.\n\n> >> However, I said *even if* above, because I don't see why it is trying\n> >> to #include <alloca.h> in the first place! ;-)\n> > \n> > I looked into my system again. The inclusion chain is:\n> > \n> > compat/regex/regex.c:77\n> > `-> compat/regex/regex_internal.h:26\n> >     `-> /usr/include/stdlib.h:138 [*1*]\n> > \n> > [*1*]: https://git.musl-libc.org/cgit/musl/tree/include/stdlib.h#n137\n> > \n> > I don't know why _GNU_SOURCE and/or _BSD_SOURCE is defined.\n> \n> ... and this explains the main cause. Hmm, as you say, why are\n> one (or both) of those pp variables set. :(\n\nOkay, I tracked it down.\n\ncompat/regex/regex.c:63\n`-> /usr/include/limits.h:4\n   `-> /usr/include/features.h:15\n\nhttps://git.musl-libc.org/cgit/musl/tree/include/features.h?id=8e452abae67db445fb6c3e37cd566c4788c2e8f3#n14\nmusl defined `_BSD_SOURCE` if none of those below macro was defined:\n\n- _BSD_SOURCE\n- _POSIX_SOURCE\n- _XOPEN_SOURCE\n- _GNU_SOURCE\n- __STRICT_ANSI__\n\nI don't think we have any business to define which one of those macros\nshould be defined in the compat code.\n\n> \n> [snip] \n> >> BTW, why are you compiling with NO_REGEX set anyway?\n> > \n> > Because I use musl-libc, and musl-libc doesn't have StartEnd\n> \n> Ah, OK. ;-)\n> \n> Well, even if the musl project accepted a PR and provided a fix, that\n> will not help you in the short term! :D\n> \n> Hmm, whatever patch you decide to send (even the original one) I think\n> you need to add an explanation of the problem to the commit message,\n> including why the patch provides a solution. (You don't have to type\n> a novel - see commit bd8f005583 :-P ).\n> \n> I haven't thought about this too much, but some options:\n> \n>   - iff the musl library sets some kind of identifying pp variable\n>     (_MUSL_LIBC_ or somesuch - I haven't looked), then you could\n>     make the '#include <alloca.h>' conditional on that variable.\n>     This has the benefit of making it obvious to people reading the\n>     code that this is specific to musl-libc.\n\nmusl's wiki's faq [musl-wiki-faq]:\n\n\tQ: Why is there no __MUSL__ macro?\n\n>   - you could simply remove that '#ifdef GAWK' block completely (Lines\n>     64->67). We set GAWK and NO_MBSUPPORT  unconditionally in the Makefile\n>     so that it compiles (see commit a997bf423d), but these particular\n>     lines simply reflect the gawk projects dislike of alloca (along with\n>     the desire to catch any attempts to add new calls which are not protected\n>     by HAVE_ALLOCA). Given that we are very unlikely to add new calls ...\n> \n>   - change the conditional on this block to (totally untested, just typing\n>     into my email client) '#if defined(GAWK) && defined(HAVE_ALLOCA)'.\n>     This should work, but it does disable the 'catch any attempts to add\n>     new _unintentional_ calls' aspect of that block; so you may as well\n>     remove it ...\n\nI'll go with your patch in the next email.\n<1a0c2b25-e283-9936-1fa2-ce51df1404dc@ramsayjones.plus.com>\n\n[musl-faq]: https://www.musl-libc.org/faq.html\n[musl-wiki-faq]: https://wiki.musl-libc.org/faq.html\n\n-- \nDanh\n"},{"id":"396334","messageId":"cover.1587996765.git.congdanhqx@gmail.com","threadId":"53297","inReplyTo":"cover.1587648870.git.congdanhqx@gmail.com","subject":"[PATCH v3 0/4] Partial fix `make sparse`","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-04-27T14:22:33Z","receivedAt":"2020-04-27T14:22:51Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"Change in v3 from v2:\n* rewrite [2/4] based on Ramsay's suggestion\n\nChange in v2 from v1:\n* = { 0 } is an idiom to zero the structure, it shouldn't be changed\n* change in [4/4] for prototype\n* ignore diffent function prototype\n\n\nĐoàn Trần Công Danh (4):\n  test-parse-pathspec-file.c: s/0/NULL/ for pointer type\n  compat/regex: move stdlib.h up in inclusion chain\n  graph.c: limit linkage of internal variable\n  progress.c: silence cgcc suggestion about internal linkage\n\n compat/regex/regex.c                | 1 +\n compat/regex/regex_internal.h       | 1 -\n graph.c                             | 2 +-\n progress.c                          | 2 +-\n progress.h                          | 8 ++++++++\n t/helper/test-parse-pathspec-file.c | 6 +++---\n t/helper/test-progress.c            | 9 +--------\n 7 files changed, 15 insertions(+), 14 deletions(-)\n\nRange-diff against v2:\n1:  c9a1812abf = 1:  c9a1812abf test-parse-pathspec-file.c: s/0/NULL/ for pointer type\n2:  290ba923b5 < -:  ---------- compat/regex: include alloca.h before undef it\n-:  ---------- > 2:  8d18c53bc8 compat/regex: move stdlib.h up in inclusion chain\n3:  39f8d85c2f = 3:  4e7580e1d1 graph.c: limit linkage of internal variable\n4:  41eecf18ed = 4:  d66d9aa677 progress.c: silence cgcc suggestion about internal linkage\n-- \n2.26.2.526.g744177e7f7\n\n"},{"id":"396335","messageId":"c9a1812abfc1d2ec804105b703f44639c0f8e3e7.1587996766.git.congdanhqx@gmail.com","threadId":"53297","inReplyTo":"cover.1587996765.git.congdanhqx@gmail.com","subject":"[PATCH v3 1/4] test-parse-pathspec-file.c: s/0/NULL/ for pointer type","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-04-27T14:22:34Z","receivedAt":"2020-04-27T14:22:53Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>\n---\n\nNotes:\n    \tstruct foo val = { 0 };\n    \n    should be taken as idiom for zero-ing structured data.\n\n    I think this should be written to CodingGuideline.\n    I'll prepare a patch for this addition\n\n t/helper/test-parse-pathspec-file.c | 6 +++---\n 1 file changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/t/helper/test-parse-pathspec-file.c b/t/helper/test-parse-pathspec-file.c\nindex 02f4ccfd2a..b3e08cef4b 100644\n--- a/t/helper/test-parse-pathspec-file.c\n+++ b/t/helper/test-parse-pathspec-file.c\n@@ -6,7 +6,7 @@\n int cmd__parse_pathspec_file(int argc, const char **argv)\n {\n \tstruct pathspec pathspec;\n-\tconst char *pathspec_from_file = 0;\n+\tconst char *pathspec_from_file = NULL;\n \tint pathspec_file_nul = 0, i;\n \n \tstatic const char *const usage[] = {\n@@ -20,9 +20,9 @@ int cmd__parse_pathspec_file(int argc, const char **argv)\n \t\tOPT_END()\n \t};\n \n-\tparse_options(argc, argv, 0, options, usage, 0);\n+\tparse_options(argc, argv, NULL, options, usage, 0);\n \n-\tparse_pathspec_file(&pathspec, 0, 0, 0, pathspec_from_file,\n+\tparse_pathspec_file(&pathspec, 0, 0, NULL, pathspec_from_file,\n \t\t\t    pathspec_file_nul);\n \n \tfor (i = 0; i < pathspec.nr; i++)\n-- \n2.26.2.526.g744177e7f7\n\n"},{"id":"396336","messageId":"8d18c53bc813865a652be148afd2292d75e1b635.1587996766.git.congdanhqx@gmail.com","threadId":"53297","inReplyTo":"cover.1587996765.git.congdanhqx@gmail.com","subject":"[PATCH v3 2/4] compat/regex: move stdlib.h up in inclusion chain","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-04-27T14:22:35Z","receivedAt":"2020-04-27T14:22:56Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"In Linux with musl libc, we have this inclusion chain:\n\ncompat/regex/regex.c:69\n`-> compat/regex/regex_internal.h\n   `-> /usr/include/stdlib.h\n      `-> /usr/include/features.h\n      `-> /usr/include/alloca.h\n\nIn that inclusion chain, `<features.h>` claims it's _BSD_SOURCE\ncompatible when it's NOT asked to be either\n{_POSIX,_GNU,_XOPEN,_BSD}_SOURCE, or __STRICT_ANSI__.\nAnd, `<stdlib.h>` will include `<alloca.h>` to be compatible with\nsoftware written for GNU and BSD. Thus, redefine `alloca` macro,\nwhich was defined before at compat/regex/regex.c:66.\n\nConsidering this is only compat code, we've taken from other project,\nit's not our business to decide which source should we adhere to.\n\nInclude `<stdlib.h>` early to prevent the redefinition of alloca.\nThis also remove a potential warning about alloca not defined on:\n\t#undef alloca\n\nHelped-by: Ramsay Jones <ramsay@ramsayjones.plus.com>\nSigned-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>\n---\n\nNotes:\n    There is another warning about un-match declaration and definition of\n    re_string_context_at.\n    \n    It's arguably, a bug in sparse itself.\n    Consider that there's a fix for it in their development version already,\n    and, we expect they'll fix the zero-ing pattern in 1/? before enable it again.\n    \n    There're no point to change that pair of declaration/definition.\n\n    This patch is technically Ramsay's work.\n    Since <alloca.h> is likely unportable, my patch will be likely unusable.\n    I took Ramsay's work and write the commit message instead.\n\n    I would love to see Ramsay's SoB on reply to this patch.\n\n compat/regex/regex.c          | 1 +\n compat/regex/regex_internal.h | 1 -\n 2 files changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/compat/regex/regex.c b/compat/regex/regex.c\nindex f3e03a9eab..e6f4a5d177 100644\n--- a/compat/regex/regex.c\n+++ b/compat/regex/regex.c\n@@ -60,6 +60,7 @@\n    #undefs RE_DUP_MAX and sets it to the right value.  */\n #include <limits.h>\n #include <stdint.h>\n+#include <stdlib.h>\n \n #ifdef GAWK\n #undef alloca\ndiff --git a/compat/regex/regex_internal.h b/compat/regex/regex_internal.h\nindex 3ee8aae59d..0bad8b841e 100644\n--- a/compat/regex/regex_internal.h\n+++ b/compat/regex/regex_internal.h\n@@ -23,7 +23,6 @@\n #include <assert.h>\n #include <ctype.h>\n #include <stdio.h>\n-#include <stdlib.h>\n #include <string.h>\n \n #if defined HAVE_LANGINFO_H || defined HAVE_LANGINFO_CODESET || defined _LIBC\n-- \n2.26.2.526.g744177e7f7\n\n"},{"id":"396337","messageId":"4e7580e1d1d844d0ed65e419fc039008740c4b7b.1587996766.git.congdanhqx@gmail.com","threadId":"53297","inReplyTo":"cover.1587996765.git.congdanhqx@gmail.com","subject":"[PATCH v3 3/4] graph.c: limit linkage of internal variable","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-04-27T14:22:36Z","receivedAt":"2020-04-27T14:22:59Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>\n---\n graph.c | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/graph.c b/graph.c\nindex 4fb25ad464..4cd9915075 100644\n--- a/graph.c\n+++ b/graph.c\n@@ -1055,7 +1055,7 @@ static void graph_output_commit_line(struct git_graph *graph, struct graph_line\n \t\tgraph_update_state(graph, GRAPH_COLLAPSING);\n }\n \n-const char merge_chars[] = {'/', '|', '\\\\'};\n+static const char merge_chars[] = {'/', '|', '\\\\'};\n \n static void graph_output_post_merge_line(struct git_graph *graph, struct graph_line *line)\n {\n-- \n2.26.2.526.g744177e7f7\n\n"},{"id":"396338","messageId":"d66d9aa677944205cdd5af77192c35ec929692ea.1587996766.git.congdanhqx@gmail.com","threadId":"53297","inReplyTo":"cover.1587996765.git.congdanhqx@gmail.com","subject":"[PATCH v3 4/4] progress.c: silence cgcc suggestion about internal linkage","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-04-27T14:22:37Z","receivedAt":"2020-04-27T14:23:01Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>\n---\n\nNotes:\n    Unify all declaration together and keep them under an ifdef.\n    \n    With the hope that no other static analysis tools complain.\n\n progress.c               | 2 +-\n progress.h               | 8 ++++++++\n t/helper/test-progress.c | 9 +--------\n 3 files changed, 10 insertions(+), 9 deletions(-)\n\ndiff --git a/progress.c b/progress.c\nindex 19805ac646..75633e9c5e 100644\n--- a/progress.c\n+++ b/progress.c\n@@ -8,6 +8,7 @@\n  * published by the Free Software Foundation.\n  */\n \n+#define GIT_TEST_PROGRESS_ONLY\n #include \"cache.h\"\n #include \"gettext.h\"\n #include \"progress.h\"\n@@ -52,7 +53,6 @@ static volatile sig_atomic_t progress_update;\n  */\n int progress_testing;\n uint64_t progress_test_ns = 0;\n-void progress_test_force_update(void); /* To silence -Wmissing-prototypes */\n void progress_test_force_update(void)\n {\n \tprogress_update = 1;\ndiff --git a/progress.h b/progress.h\nindex 847338911f..f1913acf73 100644\n--- a/progress.h\n+++ b/progress.h\n@@ -3,6 +3,14 @@\n \n struct progress;\n \n+#ifdef GIT_TEST_PROGRESS_ONLY\n+\n+extern int progress_testing;\n+extern uint64_t progress_test_ns;\n+void progress_test_force_update(void);\n+\n+#endif\n+\n void display_throughput(struct progress *progress, uint64_t total);\n void display_progress(struct progress *progress, uint64_t n);\n struct progress *start_progress(const char *title, uint64_t total);\ndiff --git a/t/helper/test-progress.c b/t/helper/test-progress.c\nindex 42b96cb103..5d05cbe789 100644\n--- a/t/helper/test-progress.c\n+++ b/t/helper/test-progress.c\n@@ -13,20 +13,13 @@\n  *\n  * See 't0500-progress-display.sh' for examples.\n  */\n+#define GIT_TEST_PROGRESS_ONLY\n #include \"test-tool.h\"\n #include \"gettext.h\"\n #include \"parse-options.h\"\n #include \"progress.h\"\n #include \"strbuf.h\"\n \n-/*\n- * These are defined in 'progress.c', but are not exposed in 'progress.h',\n- * because they are exclusively for testing.\n- */\n-extern int progress_testing;\n-extern uint64_t progress_test_ns;\n-void progress_test_force_update(void);\n-\n int cmd__progress(int argc, const char **argv)\n {\n \tint total = 0;\n-- \n2.26.2.526.g744177e7f7\n\n"},{"id":"396347","messageId":"f3af49c7-6c35-d2f6-c87c-e7342b1c2b6f@ramsayjones.plus.com","threadId":"53297","inReplyTo":"20200427010821.GD14800@danh.dev","subject":"Re: [PATCH v2 2/4] compat/regex: include alloca.h before undef it","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2020-04-27T16:28:03Z","receivedAt":"2020-04-27T16:28:10Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 27/04/2020 02:08, Danh Doan wrote:\n[snip]\n\n>>> musl's alloca.h is available here:\n>>>\n>>> https://git.musl-libc.org/cgit/musl/tree/include/alloca.h\n>>\n>> Hmm, OK, so that partly explains the problem. I wonder if the\n>> musl guys would accept a bug report?\n> \n> I don't think they have a policy of no `#undef` whatsoever.\n\nThat's fair enough.\n\n> But, I think they're picky when come to C-correctly and\n> POSIX-correctly.\n> Does C or POSIX define alloca(3) at all?\n\nNo alloca() is not in either the POSIX or C standard(s).\nThis was an extension from the early days of BSD Unix.\n\nFor some reason, I thought you had to explicitly '#include <alloca.h>'\nto use it, but it appears that (by default) you get a bonus include\nfrom the <stdlib.h> header, unless you restrict the headers using the\nvarious macros and/or compiler command-line options.\n\nAs it happens, even on glibc systems, the <alloca.h> header is included\nby the <stdlib.h> header, unless you take steps to suppress it. So, we\nwould have had the same issue, if it wasn't for the aforementioned\n'#undef alloca' the the glibc header file.\n\nWhen I need to look at pp output, while debugging things like this,\nI cherry-pick a patch to the Makefile:\n\n  $ git diff\n  diff --git a/Makefile b/Makefile\n  index 6d5cee270c..cd8753bf54 100644\n  --- a/Makefile\n  +++ b/Makefile\n  @@ -2423,6 +2423,9 @@ $(ASM_OBJ): %.o: %.S GIT-CFLAGS $(missing_dep_dirs)\n   %.s: %.c GIT-CFLAGS FORCE\n          $(QUIET_CC)$(CC) -o $@ -S $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) $<\n   \n  +%.i: %.c GIT-CFLAGS FORCE\n  +       $(QUIET_CC)$(CC) $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) -E $< >$*.i\n  +\n   ifdef USE_COMPUTED_HEADER_DEPENDENCIES\n   # Take advantage of gcc's on-the-fly dependency generation\n   # See <http://gcc.gnu.org/gcc-3.0/features.html>.\n  @@ -2474,7 +2477,7 @@ http-walker.sp http-walker.s http-walker.o: EXTRA_CPPFLAGS = -DNO_EXPAT\n   endif\n   \n   ifdef NO_REGEX\n  -compat/regex/regex.sp compat/regex/regex.o: EXTRA_CPPFLAGS = \\\n  +compat/regex/regex.i compat/regex/regex.sp compat/regex/regex.o: EXTRA_CPPFLAGS = \\\n          -DGAWK -DNO_MBSUPPORT\n   endif\n   \n  $ \n\n[The second hunk above is not actually part of the cherry-picked patch,\nbut I needed it in this instance to get GAWK and NO_MBSUPPORT passed to\nthe compiler!]\n\n  $ make NO_REGEX=1 compat/regex/regex.i\n      CC compat/regex/regex.i\n  $ vim compat/regex/regex.i\n  $ \n\n... which shows <alloca.h> is indeed being #included from <stdlib.h>.\n[it is protected by a __USE_MISC pp variable, but I didn't bother to\ntrack it down! ;-)]\n\nATB,\nRamsay Jones\n\n  \n"},{"id":"396349","messageId":"2c62be65-7350-aa52-dead-46ddea7baca6@ramsayjones.plus.com","threadId":"53297","inReplyTo":"cover.1587996765.git.congdanhqx@gmail.com","subject":"Re: [PATCH v3 0/4] Partial fix `make sparse`","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2020-04-27T16:35:17Z","receivedAt":"2020-04-27T16:35:27Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 27/04/2020 15:22, Đoàn Trần Công Danh wrote:\n> Change in v3 from v2:\n> * rewrite [2/4] based on Ramsay's suggestion\n\nYep, these all look good to me. Thanks!\n\nATB,\nRamsay Jones\n\n> \n> Change in v2 from v1:\n> * = { 0 } is an idiom to zero the structure, it shouldn't be changed\n> * change in [4/4] for prototype\n> * ignore diffent function prototype\n> \n> \n> Đoàn Trần Công Danh (4):\n>   test-parse-pathspec-file.c: s/0/NULL/ for pointer type\n>   compat/regex: move stdlib.h up in inclusion chain\n>   graph.c: limit linkage of internal variable\n>   progress.c: silence cgcc suggestion about internal linkage\n> \n>  compat/regex/regex.c                | 1 +\n>  compat/regex/regex_internal.h       | 1 -\n>  graph.c                             | 2 +-\n>  progress.c                          | 2 +-\n>  progress.h                          | 8 ++++++++\n>  t/helper/test-parse-pathspec-file.c | 6 +++---\n>  t/helper/test-progress.c            | 9 +--------\n>  7 files changed, 15 insertions(+), 14 deletions(-)\n> \n> Range-diff against v2:\n> 1:  c9a1812abf = 1:  c9a1812abf test-parse-pathspec-file.c: s/0/NULL/ for pointer type\n> 2:  290ba923b5 < -:  ---------- compat/regex: include alloca.h before undef it\n> -:  ---------- > 2:  8d18c53bc8 compat/regex: move stdlib.h up in inclusion chain\n> 3:  39f8d85c2f = 3:  4e7580e1d1 graph.c: limit linkage of internal variable\n> 4:  41eecf18ed = 4:  d66d9aa677 progress.c: silence cgcc suggestion about internal linkage\n> \n"},{"id":"396350","messageId":"1d0fb62f-95e0-3c17-ee27-2a5460590947@ramsayjones.plus.com","threadId":"53297","inReplyTo":"8d18c53bc813865a652be148afd2292d75e1b635.1587996766.git.congdanhqx@gmail.com","subject":"Re: [PATCH v3 2/4] compat/regex: move stdlib.h up in inclusion chain","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2020-04-27T16:41:53Z","receivedAt":"2020-04-27T16:41:59Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 27/04/2020 15:22, Đoàn Trần Công Danh wrote:\n> In Linux with musl libc, we have this inclusion chain:\n> \n> compat/regex/regex.c:69\n> `-> compat/regex/regex_internal.h\n>    `-> /usr/include/stdlib.h\n>       `-> /usr/include/features.h\n>       `-> /usr/include/alloca.h\n> \n> In that inclusion chain, `<features.h>` claims it's _BSD_SOURCE\n> compatible when it's NOT asked to be either\n> {_POSIX,_GNU,_XOPEN,_BSD}_SOURCE, or __STRICT_ANSI__.\n> And, `<stdlib.h>` will include `<alloca.h>` to be compatible with\n> software written for GNU and BSD. Thus, redefine `alloca` macro,\n> which was defined before at compat/regex/regex.c:66.\n> \n> Considering this is only compat code, we've taken from other project,\n> it's not our business to decide which source should we adhere to.\n> \n> Include `<stdlib.h>` early to prevent the redefinition of alloca.\n> This also remove a potential warning about alloca not defined on:\n> \t#undef alloca\n> \n> Helped-by: Ramsay Jones <ramsay@ramsayjones.plus.com>\n> Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>\n> ---\n> \n> Notes:\n>     There is another warning about un-match declaration and definition of\n>     re_string_context_at.\n>     \n>     It's arguably, a bug in sparse itself.\n>     Consider that there's a fix for it in their development version already,\n>     and, we expect they'll fix the zero-ing pattern in 1/? before enable it again.\n\nAhem, yes I still haven't found time to find that patch yet.\nSorry about that. :(\n\n>     There're no point to change that pair of declaration/definition.\n> \n>     This patch is technically Ramsay's work.\n>     Since <alloca.h> is likely unportable, my patch will be likely unusable.\n>     I took Ramsay's work and write the commit message instead.\n> \n>     I would love to see Ramsay's SoB on reply to this patch.\n\nI think 'Helped-by:' is all that is necessary (you did the hard work,\nincluding testing on musl-libc), but if you prefer:\n\nSigned-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>\n\nATB,\nRamsay Jones\n\n> \n>  compat/regex/regex.c          | 1 +\n>  compat/regex/regex_internal.h | 1 -\n>  2 files changed, 1 insertion(+), 1 deletion(-)\n> \n> diff --git a/compat/regex/regex.c b/compat/regex/regex.c\n> index f3e03a9eab..e6f4a5d177 100644\n> --- a/compat/regex/regex.c\n> +++ b/compat/regex/regex.c\n> @@ -60,6 +60,7 @@\n>     #undefs RE_DUP_MAX and sets it to the right value.  */\n>  #include <limits.h>\n>  #include <stdint.h>\n> +#include <stdlib.h>\n>  \n>  #ifdef GAWK\n>  #undef alloca\n> diff --git a/compat/regex/regex_internal.h b/compat/regex/regex_internal.h\n> index 3ee8aae59d..0bad8b841e 100644\n> --- a/compat/regex/regex_internal.h\n> +++ b/compat/regex/regex_internal.h\n> @@ -23,7 +23,6 @@\n>  #include <assert.h>\n>  #include <ctype.h>\n>  #include <stdio.h>\n> -#include <stdlib.h>\n>  #include <string.h>\n>  \n>  #if defined HAVE_LANGINFO_H || defined HAVE_LANGINFO_CODESET || defined _LIBC\n> \n"},{"id":"396352","messageId":"20200427164649.GA31366@danh.dev","threadId":"53297","inReplyTo":"f3af49c7-6c35-d2f6-c87c-e7342b1c2b6f@ramsayjones.plus.com","subject":"Re: [PATCH v2 2/4] compat/regex: include alloca.h before undef it","fromName":"Danh Doan","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-04-27T16:46:49Z","receivedAt":"2020-04-27T16:46:54Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2020-04-27 17:28:03+0100, Ramsay Jones <ramsay@ramsayjones.plus.com> wrote:\n> No alloca() is not in either the POSIX or C standard(s).\n> This was an extension from the early days of BSD Unix.\n\nOkay, I saw it was mentioned in GNU manpage for alloca(3)\n\n \n> For some reason, I thought you had to explicitly '#include <alloca.h>'\n> to use it, but it appears that (by default) you get a bonus include\n> from the <stdlib.h> header, unless you restrict the headers using the\n> various macros and/or compiler command-line options.\n\nIt looks like <alloca.h> is GNU's invention.\n\n*BSD defined it in <stdlib.h>:\nhttps://www.freebsd.org/cgi/man.cgi?alloca\nhttps://man.openbsd.org/alloca\nhttps://netbsd.gw.com/cgi-bin/man-cgi?alloca+3+NetBSD-current\n\nEven GNU's alloca(3) says:\n\n       Normally, gcc(1) translates calls to alloca() with inlined code.  This\n       is not done when either the -ansi, -std=c89, -std=c99, or the -std=c11\n       option is given and the header <alloca.h> is not included.  Otherwise,\n       (without an -ansi or -std=c* option) the glibc version of <stdlib.h>\n       includes <alloca.h> \n\n> As it happens, even on glibc systems, the <alloca.h> header is included\n> by the <stdlib.h> header, unless you take steps to suppress it. So, we\n> would have had the same issue, if it wasn't for the aforementioned\n> '#undef alloca' the the glibc header file.\n\nFrom above information, I think it's fine to include <stdlib.h> first.\nIt's AT&T Unix's invention and everyone seems to follow it (except Windows,\nbut the lack of complains from our Windows friends may signify that\ntheir alloca is fine already).\n\nI've sent it already for v3.\n\n \n> When I need to look at pp output, while debugging things like this,\n> I cherry-pick a patch to the Makefile:\n> \n>   $ git diff\n>   diff --git a/Makefile b/Makefile\n>   index 6d5cee270c..cd8753bf54 100644\n>   --- a/Makefile\n>   +++ b/Makefile\n>   @@ -2423,6 +2423,9 @@ $(ASM_OBJ): %.o: %.S GIT-CFLAGS $(missing_dep_dirs)\n>    %.s: %.c GIT-CFLAGS FORCE\n>           $(QUIET_CC)$(CC) -o $@ -S $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) $<\n>    \n>   +%.i: %.c GIT-CFLAGS FORCE\n>   +       $(QUIET_CC)$(CC) $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) -E $< >$*.i\n>   +\n>    ifdef USE_COMPUTED_HEADER_DEPENDENCIES\n>    # Take advantage of gcc's on-the-fly dependency generation\n>    # See <http://gcc.gnu.org/gcc-3.0/features.html>.\n>   @@ -2474,7 +2477,7 @@ http-walker.sp http-walker.s http-walker.o: EXTRA_CPPFLAGS = -DNO_EXPAT\n>    endif\n>    \n>    ifdef NO_REGEX\n>   -compat/regex/regex.sp compat/regex/regex.o: EXTRA_CPPFLAGS = \\\n>   +compat/regex/regex.i compat/regex/regex.sp compat/regex/regex.o: EXTRA_CPPFLAGS = \\\n>           -DGAWK -DNO_MBSUPPORT\n>    endif\n>    \n>   $ \n\nI think it's worth to have this included. `.s` rules is there, anyway.\nPersonally, I've run this to trace the inclusion:\n\n\tmake V=1 CFLAGS=-E compat/regex/regex.o compat/regex/regex.sp\n\n\n-- \nDanh\n"},{"id":"396356","messageId":"55e4e613-fc64-2626-1e06-47d6151bafef@ramsayjones.plus.com","threadId":"53297","inReplyTo":"20200427164649.GA31366@danh.dev","subject":"Re: [PATCH v2 2/4] compat/regex: include alloca.h before undef it","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2020-04-27T17:21:24Z","receivedAt":"2020-04-27T17:21:29Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 27/04/2020 17:46, Danh Doan wrote:\n[snip]\n\n> It looks like <alloca.h> is GNU's invention.\n> \n> *BSD defined it in <stdlib.h>:\n> https://www.freebsd.org/cgi/man.cgi?alloca\n> https://man.openbsd.org/alloca\n> https://netbsd.gw.com/cgi-bin/man-cgi?alloca+3+NetBSD-current\n\nYeah, that would make sense. It's been about 25 years since I used\na BSD based system (Hmm, Irix changed its base from AT&T to BSD at\none point; or was it the other way round - I forget!)\n\n>> As it happens, even on glibc systems, the <alloca.h> header is included\n>> by the <stdlib.h> header, unless you take steps to suppress it. So, we\n>> would have had the same issue, if it wasn't for the aforementioned\n>> '#undef alloca' the the glibc header file.\n> \n>>From above information, I think it's fine to include <stdlib.h> first.\n> It's AT&T Unix's invention and everyone seems to follow it (except Windows,\n> but the lack of complains from our Windows friends may signify that\n> their alloca is fine already).\n> \n> I've sent it already for v3.\n\nYep, looks good.\n\n>> When I need to look at pp output, while debugging things like this,\n>> I cherry-pick a patch to the Makefile:\n>>\n>>   $ git diff\n>>   diff --git a/Makefile b/Makefile\n>>   index 6d5cee270c..cd8753bf54 100644\n>>   --- a/Makefile\n>>   +++ b/Makefile\n>>   @@ -2423,6 +2423,9 @@ $(ASM_OBJ): %.o: %.S GIT-CFLAGS $(missing_dep_dirs)\n>>    %.s: %.c GIT-CFLAGS FORCE\n>>           $(QUIET_CC)$(CC) -o $@ -S $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) $<\n>>    \n>>   +%.i: %.c GIT-CFLAGS FORCE\n>>   +       $(QUIET_CC)$(CC) $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) -E $< >$*.i\n>>   +\n>>    ifdef USE_COMPUTED_HEADER_DEPENDENCIES\n>>    # Take advantage of gcc's on-the-fly dependency generation\n>>    # See <http://gcc.gnu.org/gcc-3.0/features.html>.\n>>   @@ -2474,7 +2477,7 @@ http-walker.sp http-walker.s http-walker.o: EXTRA_CPPFLAGS = -DNO_EXPAT\n>>    endif\n>>    \n>>    ifdef NO_REGEX\n>>   -compat/regex/regex.sp compat/regex/regex.o: EXTRA_CPPFLAGS = \\\n>>   +compat/regex/regex.i compat/regex/regex.sp compat/regex/regex.o: EXTRA_CPPFLAGS = \\\n>>           -DGAWK -DNO_MBSUPPORT\n>>    endif\n>>    \n>>   $ \n> \n> I think it's worth to have this included. `.s` rules is there, anyway.\n\nHmm, I can't remember if I ever actually submitted a patch; I've had\nthis patch floating in my git repo for about 10 years or so! ;-)\nI don't use it very often, but it's very useful when needed.\n\nATB,\nRamsay Jones\n\n"},{"id":"396782","messageId":"nycvar.QRO.7.76.6.2005012200470.18039@tvgsbejvaqbjf.bet","threadId":"53297","inReplyTo":"45522b6a-76a4-a7d9-3cce-a3581aaca899@ramsayjones.plus.com","subject":"Re: [PATCH 0/4] fix make sparse warning","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2020-05-01T20:02:31Z","receivedAt":"2020-05-01T20:02:40Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 26 Apr 2020, Ramsay Jones wrote:\n\n> On 26/04/2020 04:32, Danh Doan wrote:\n> > On 2020-04-25 15:13:53+0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> >> Hi Danh,\n> >>\n> >> On Thu, 23 Apr 2020, Đoàn Trần Công Danh wrote:\n> >>\n> >>> It's happened that I tried to run make check on project that support autoconf.\n> >>> Git's Makefile told me to run `make sparse` instead.\n> >>>\n> >>> I /think/ if we have a rule in Makefile, we should adhere to it.\n> >>> I also fix another change in ds/blame-on-bloom, which I think it's worth to\n> >>> fix, see: <20200423133937.GA1984@danh.dev>\n> >>\n> >> FWIW there is still an Azure Pipeline building `sparse` for Ubuntu every\n> >> two weeks: https://dev.azure.com/git/git/_build?definitionId=10&_a=summary\n> >>\n> >> I created this Pipeline in order to support the proposed project at\n> >> https://github.com/gitgitgadget/git/issues/345 which is: teach our CI\n> >> builds to run `make sparse`.\n> >>\n> >> Maybe it is time to tackle that?\n> >\n> > I don't think it's ready, yet!\n>\n> Heh, not too long ago, the 'master' and 'next' branches were 'sparse clean'.\n> (on non NO_REGEX builds anyway, and even on those for some of us. ;-) )\n\nMaybe we should spend the time to make it \"sparse clean\" again.\n\nOf course, that would mean that reftables would have a ton of work in\nfront of it (not that it does already...).\n\n> The 'pu' branch was frequently 'unclean', of course.\n\nBut mostly because there was no automated job to tell contributors about\nit.\n\nCiao,\nDscho\n\n>\n> ATB,\n> Ramsay Jones\n>\n> >\n> > May be it's.\n> >\n> > But we'll need\n> >\n> > \tmake sparse |\n> > \tgrep -v -e 'plain integer as NULL pointer' \\\n> > \t\t-e 'redeclared with different type'\n> >\n> > The first one for:\n> >\n> > \tstruct foo val = { 0 };\n> >\n> > to zero structure.\n> >\n> > The second one for different in declaration and definition (which is\n> > fixed in sparse's master).\n> >\n> >\n>\n"},{"id":"396783","messageId":"nycvar.QRO.7.76.6.2005012206300.18039@tvgsbejvaqbjf.bet","threadId":"53297","inReplyTo":"d66d9aa677944205cdd5af77192c35ec929692ea.1587996766.git.congdanhqx@gmail.com","subject":"Re: [PATCH v3 4/4] progress.c: silence cgcc suggestion about internal linkage","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2020-05-01T20:09:52Z","receivedAt":"2020-05-01T20:10:09Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 27 Apr 2020, Đoàn Trần Công Danh wrote:\n\n> diff --git a/progress.h b/progress.h\n> index 847338911f..f1913acf73 100644\n> --- a/progress.h\n> +++ b/progress.h\n> @@ -3,6 +3,14 @@\n>\n>  struct progress;\n>\n> +#ifdef GIT_TEST_PROGRESS_ONLY\n> +\n> +extern int progress_testing;\n> +extern uint64_t progress_test_ns;\n> +void progress_test_force_update(void);\n> +\n> +#endif\n> +\n>  void display_throughput(struct progress *progress, uint64_t total);\n>  void display_progress(struct progress *progress, uint64_t n);\n>  struct progress *start_progress(const char *title, uint64_t total);\n\nA slightly cleaner strategy would be to add a separate header file, say,\n`progress-internal.h` or `internal/progress.h` to declare the variables\nand the function.\n\nI guess at some stage we really need to define a proper API of libgit.a.\nJust because we refuse to declare such an API doesn't mean that people\ndon't use libgit.a in that way (e.g. cgit, cinnabar). We might just as\nwell face reality and split up `cache.h` and put the API part into header\nfiles in a subdirectory `include/`.\n\nCiao,\nDscho\n"},{"id":"397832","messageId":"20200514213710.vxm6vrkggdfad6kd@ltop.local","threadId":"53297","inReplyTo":"xmqqd07xem9l.fsf@gitster.c.googlers.com","subject":"Re: [PATCH 1/4] C: s/0/NULL/ for pointer type","fromName":"Luc Van Oostenryck","fromEmail":"luc.vanoostenryck@gmail.com","sentAt":"2020-05-14T21:37:10Z","receivedAt":"2020-05-14T21:37:16Z","isPatch":true,"sender":{"key":"luc.vanoostenryck@gmail.com","avatar":"https://avatars.githubusercontent.com/u/16168334?v=4"},"body":"On Thu, Apr 23, 2020 at 05:54:30PM -0700, Junio C Hamano wrote:\n> Ramsay Jones <ramsay@ramsayjones.plus.com> writes:\n> \n> > Actually, I have a patch somewhere which suppressed the sparse warning\n> > for the '= { 0 }' token sequence used in these initializations. However,\n> > I don't seem to be able to find them at the moment! :(\n> \n> AHHHHHhhhhhhhh.  \n> \n> Thanks for reminding.  Yeah, I recall that the concensus of those\n> who were vocal in that old discussion [*1*] was that \"= { 0 }\"\n> should be taken as an idiom and should not be subject to s/0/NULL/\n> conversion.\n> \n> > [Luc, this topic came up on the sparse and kernel mailing-lists at one\n> > point, but I didn't get around to posting my patch to the list - something\n> > came up. Hopefully, I will find some time to find it and post it soon.]\n> \n> \n> [References]\n> \n> *1*\n> \n> https://lore.kernel.org/git/e6796c60-a870-e761-3b07-b680f934c537@ramsayjones.plus.com/\n\nSorry for the late reply.\n\nI hadn't seen this old discussion but I vaguely remember 2 emails about\nthis problem, probaly on lkml, without a real discussion, but where the\nopinion was the opposite.\n\nPersonally, I prefer '= { }' but yes it's not legit and it seems that\nsome compilers don't like it. I'll be glad to add an option to Sparse\nto shut up the warnings now given by '{ 0 }'.\n\n-- Luc\n"}]}