{"thread":{"id":"51471","subject":"[PATCH] range-diff: fix some 'hdr-check' and sparse warnings","startedAt":"2019-07-11T22:03:07Z","lastAt":"2020-10-05T12:25:44Z","messageCount":23,"participants":["Ramsay Jones","Johannes Sixt","Junio C Hamano","Carlo Arenas","Jeff King","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"378873","messageId":"e6796c60-a870-e761-3b07-b680f934c537@ramsayjones.plus.com","threadId":"51471","inReplyTo":null,"subject":"[PATCH] range-diff: fix some 'hdr-check' and sparse warnings","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2019-07-11T22:03:03Z","receivedAt":"2019-07-11T22:03:07Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\nSigned-off-by: Ramsay Jones \n---\n\nHi Thomas,\n\nIf you need to re-roll your 'tg/range-diff-output-update' branch, could\nyou please squash (parts) of this into the relevant patches.\n\nThe first hunk fixes a couple of 'hdr-check' warnings:\n\n $ diff nhcout phcout | head\n 4a5,13\n > apply.h:146:22: error: ‘GIT_MAX_HEXSZ’ undeclared here (not in a function); did you mean ‘NI_MAXHOST’?\n > char old_oid_prefix[GIT_MAX_HEXSZ + 1];\n > ^~~~~~~~~~~~~\n > NI_MAXHOST\n > apply.h:151:19: error: array type has incomplete element type ‘struct object_id’\n > struct object_id threeway_stage[3];\n > ^~~~~~~~~~~~~~\n > Makefile:2775: recipe for target 'apply.hco' failed\n > make: *** [apply.hco] Error 1\n $ \n\nand needs to be applied to commit b9f62a7e24 (\"apply: make parse_git_header\npublic\", 2019-07-08).\n\nThe second hunk fixes a sparse 'Using plain integer as NULL pointer'\nwarning, and needs to be applied to commit 04539fc67b (\"range-diff: add\nsection header instead of diff header\", 2019-07-08).\n\nThanks!\n\nATB,\nRamsay Jones\n\n apply.h | 1 +\n range-diff.c | 2 +-\n 2 files changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/apply.h b/apply.h\nindex ade50f66c5..c8c9287cb2 100644\n--- a/apply.h\n+++ b/apply.h\n@@ -3,6 +3,7 @@\n \n #include \"lockfile.h\"\n #include \"string-list.h\"\n+#include \"hash.h\"\n \n struct repository;\n \ndiff --git a/range-diff.c b/range-diff.c\nindex ba1e9a4265..0f24a4ad12 100644\n--- a/range-diff.c\n+++ b/range-diff.c\n@@ -102,7 +102,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-- \n2.22.0\n"},{"id":"378876","messageId":"41a60e60-d2c0-7d54-5456-e44d106548a4@kdbg.org","threadId":"51471","inReplyTo":"e6796c60-a870-e761-3b07-b680f934c537@ramsayjones.plus.com","subject":"Re: [PATCH] range-diff: fix some 'hdr-check' and sparse warnings","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2019-07-12T05:21:08Z","receivedAt":"2019-07-12T05:21:12Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 12.07.19 um 00:03 schrieb Ramsay Jones:\n> diff --git a/range-diff.c b/range-diff.c\n> index ba1e9a4265..0f24a4ad12 100644\n> --- a/range-diff.c\n> +++ b/range-diff.c\n> @@ -102,7 +102,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\nThere is nothing wrong with 0 here. IMHO, zero-initialization should\n*always* be written as = { 0 } and nothing else. Changing 0 to NULL to\npacify sparse encourages a wrong style.\n\n-- Hannes\n"},{"id":"378895","messageId":"xmqqy313p5hn.fsf@gitster-ct.c.googlers.com","threadId":"51471","inReplyTo":"41a60e60-d2c0-7d54-5456-e44d106548a4@kdbg.org","subject":"Re: [PATCH] range-diff: fix some 'hdr-check' and sparse warnings","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-07-12T16:44:36Z","receivedAt":"2019-07-12T16:44:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Am 12.07.19 um 00:03 schrieb Ramsay Jones:\n>> diff --git a/range-diff.c b/range-diff.c\n>> index ba1e9a4265..0f24a4ad12 100644\n>> --- a/range-diff.c\n>> +++ b/range-diff.c\n>> @@ -102,7 +102,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>\n> There is nothing wrong with 0 here. IMHO, zero-initialization should\n> *always* be written as = { 0 } and nothing else. Changing 0 to NULL to\n> pacify sparse encourages a wrong style.\n>\n> -- Hannes\n\nHmm, care to elaborate a bit? Certainly, we have a clear preference\nbetween these two:\n\n\tstruct patch patch;\n\tpatch.new_name = 0;\n\tpatch.new_name = NULL;\n\nwhere the \"char *new_name\" field is the first one in the structure.\nWe always try to write the latter, even though we know they ought to\nbe equivalent to the language lawyers.\n\nIs the reason why you say 0 is fine here because we consider\n\n\tstruct patch patch, *dpatch;\n\tmemset(&patch, 0, sizeof(patch));\n\tdpatch = xcalloc(1, sizeof(patch));\n\nare perfectly good way to trivially iniitialize an instance of the\nstruct?\n\nDo we want to talk to sparse folks about this?\n\n"},{"id":"378918","messageId":"ec635d0d-00ca-2419-3c1a-9b0343b46daa@kdbg.org","threadId":"51471","inReplyTo":"xmqqy313p5hn.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH] range-diff: fix some 'hdr-check' and sparse warnings","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2019-07-13T10:44:20Z","receivedAt":"2019-07-13T10:44:27Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 12.07.19 um 18:44 schrieb Junio C Hamano:\n> Johannes Sixt writes:\n> \n>> Am 12.07.19 um 00:03 schrieb Ramsay Jones:\n>>> diff --git a/range-diff.c b/range-diff.c\n>>> index ba1e9a4265..0f24a4ad12 100644\n>>> --- a/range-diff.c\n>>> +++ b/range-diff.c\n>>> @@ -102,7 +102,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>>\n>> There is nothing wrong with 0 here. IMHO, zero-initialization should\n>> *always* be written as = { 0 } and nothing else. Changing 0 to NULL to\n>> pacify sparse encourages a wrong style.\n> \n> Hmm, care to elaborate a bit? Certainly, we have a clear preference\n> between these two:\n> \n> \tstruct patch patch;\n> \tpatch.new_name = 0;\n> \tpatch.new_name = NULL;\n> \n> where the \"char *new_name\" field is the first one in the structure.\n> We always try to write the latter, even though we know they ought to\n> be equivalent to the language lawyers.\n\nI'm not questioning this case; the latter form is clearly preferable.\n\nUsing only = { 0 } for zero-initialization makes the code immune to\nrearrangements of the struct members. That is not the case with = { NULL\n} because it requires that the first member is a pointer; if\nrearrangement makes the first member a non-pointer, the initializations\nmust be adjusted.\n\nOn the other hand, I'm not arguing that\n\n struct string_list dup_it = { NULL, 0, 0, 1, NULL };\n\nshould be written as\n\n struct string_list dup_it = { 0, 0, 0, 1, 0 };\n\nI'm only complaining about the single-initializer = { 0 } \"please\ninitialize this whole struct with zero values\" form.\n\n> Is the reason why you say 0 is fine here because we consider\n> \n> \tstruct patch patch, *dpatch;\n> \tmemset(&patch, 0, sizeof(patch));\n> \tdpatch = xcalloc(1, sizeof(patch));\n> \n> are perfectly good way to trivially iniitialize an instance of the\n> struct?\n\nAbsolutely not. Both forms are evildoing as far as struct initialization\nis concerned because they ignore the types of the members. The memset\nform should always be replaced by = { 0 }. The correct replacement for\nthe xcalloc form would be\n\n\tstruct patch zero = { 0 };\n\tstruct patch *dpatch = xmalloc(sizeof(*dpatch));\n\t*dpatch = zero;\n\nbut I do understand that this transformation is unacceptably verbose.\n\n> Do we want to talk to sparse folks about this?\n\nI've no idea which camp they are in. How would they respond to an\nexceptional case that is also very much a matter of taste?\n\n-- Hannes\n"},{"id":"378919","messageId":"f72d8bb6-f55d-a78f-68b4-c015c1e43f25@kdbg.org","threadId":"51471","inReplyTo":"ec635d0d-00ca-2419-3c1a-9b0343b46daa@kdbg.org","subject":"Re: [PATCH] range-diff: fix some 'hdr-check' and sparse warnings","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2019-07-13T12:18:18Z","receivedAt":"2019-07-13T12:18:25Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 13.07.19 um 12:44 schrieb Johannes Sixt:\n> Am 12.07.19 um 18:44 schrieb Junio C Hamano:\n>> Johannes Sixt writes:\n>>\n>>> Am 12.07.19 um 00:03 schrieb Ramsay Jones:\n>>>> diff --git a/range-diff.c b/range-diff.c\n>>>> index ba1e9a4265..0f24a4ad12 100644\n>>>> --- a/range-diff.c\n>>>> +++ b/range-diff.c\n>>>> @@ -102,7 +102,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>>>\n>>> There is nothing wrong with 0 here. IMHO, zero-initialization should\n>>> *always* be written as = { 0 } and nothing else. Changing 0 to NULL to\n>>> pacify sparse encourages a wrong style.\n>>\n>> Hmm, care to elaborate a bit? Certainly, we have a clear preference\n>> between these two:\n>>\n>> \tstruct patch patch;\n>> \tpatch.new_name = 0;\n>> \tpatch.new_name = NULL;\n>>\n>> where the \"char *new_name\" field is the first one in the structure.\n>> We always try to write the latter, even though we know they ought to\n>> be equivalent to the language lawyers.\n> \n> I'm not questioning this case; the latter form is clearly preferable.\n> \n> Using only = { 0 } for zero-initialization makes the code immune to\n> rearrangements of the struct members. That is not the case with = { NULL\n> } because it requires that the first member is a pointer; if\n> rearrangement makes the first member a non-pointer, the initializations\n> must be adjusted.\n> \n> On the other hand, I'm not arguing that\n> \n> struct string_list dup_it = { NULL, 0, 0, 1, NULL };\n> \n> should be written as\n> \n> struct string_list dup_it = { 0, 0, 0, 1, 0 };\n> \n> I'm only complaining about the single-initializer = { 0 } \"please\n\nOf course, I'm not \"complaining about\" it; I'm \"arguing for\" it...\n\n> initialize this whole struct with zero values\" form.\n> \n>> Is the reason why you say 0 is fine here because we consider\n>>\n>> \tstruct patch patch, *dpatch;\n>> \tmemset(&patch, 0, sizeof(patch));\n>> \tdpatch = xcalloc(1, sizeof(patch));\n>>\n>> are perfectly good way to trivially iniitialize an instance of the\n>> struct?\n> \n> Absolutely not. Both forms are evildoing as far as struct initialization\n> is concerned because they ignore the types of the members. The memset\n> form should always be replaced by = { 0 }. The correct replacement for\n> the xcalloc form would be\n> \n> \tstruct patch zero = { 0 };\n> \tstruct patch *dpatch = xmalloc(sizeof(*dpatch));\n> \t*dpatch = zero;\n> \n> but I do understand that this transformation is unacceptably verbose.\n> \n>> Do we want to talk to sparse folks about this?\n> \n> I've no idea which camp they are in. How would they respond to an\n> exceptional case that is also very much a matter of taste?\n> \n> -- Hannes\n> \n\n"},{"id":"378920","messageId":"CAPUEspgmkP_7K=eap3LpQSCp-k6HZ7FK-_LaBoBiJR1CqEMYmA@mail.gmail.com","threadId":"51471","inReplyTo":"ec635d0d-00ca-2419-3c1a-9b0343b46daa@kdbg.org","subject":"Re: [PATCH] range-diff: fix some 'hdr-check' and sparse warnings","fromName":"Carlo Arenas","fromEmail":"carenas@gmail.com","sentAt":"2019-07-13T12:56:14Z","receivedAt":"2019-07-13T12:56:30Z","isPatch":true,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Sat, Jul 13, 2019 at 3:46 AM Johannes Sixt wrote:\n>\n> Using only = { 0 } for zero-initialization makes the code immune to\n> rearrangements of the struct members.\n\nBut only by forcing to set whichever is the first element to 0, which is\nexactly what sparse is complaining about, since it happens to be a\npointer.\n\n> That is not the case with = { NULL\n> } because it requires that the first member is a pointer; if\n> rearrangement makes the first member a non-pointer, the initializations\n> must be adjusted.\n\nluckily sparse will complain loudly in that case as well as shown by:\n\n$ cat t.c\n#include \n\nint main(int argc, char *argv[]) {\n struct {\n char i;\n char *p;\n } s = {NULL};\n return 0;\n}\n$ sparse t.c\nt.c:7:10: warning: incorrect type in initializer (different base types)\nt.c:7:10: expected char i\nt.c:7:10: got void *\n\nCarlo\n"},{"id":"378921","messageId":"xmqq1rytpqse.fsf@gitster-ct.c.googlers.com","threadId":"51471","inReplyTo":"ec635d0d-00ca-2419-3c1a-9b0343b46daa@kdbg.org","subject":"Re: [PATCH] range-diff: fix some 'hdr-check' and sparse warnings","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-07-13T21:29:05Z","receivedAt":"2019-07-13T21:29:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n>> Hmm, care to elaborate a bit? Certainly, we have a clear preference\n>> between these two:\n>> \n>> \tstruct patch patch;\n>> \tpatch.new_name = 0;\n>> \tpatch.new_name = NULL;\n>> \n>> where the \"char *new_name\" field is the first one in the structure.\n>> We always try to write the latter, even though we know they ought to\n>> be equivalent to the language lawyers.\n>\n> I'm not questioning this case; the latter form is clearly preferable.\n>\n> Using only = { 0 } for zero-initialization makes the code immune to\n> rearrangements of the struct members. That is not the case with = { NULL\n> } because it requires that the first member is a pointer; if\n> rearrangement makes the first member a non-pointer, the initializations\n> must be adjusted.\n\nI do not think this position is maintainable, especially if you\nagree with me (and everybody else, including sparse) that this is a\nbad idea:\n\n> struct string_list dup_it = { 0, 0, 0, 1, 0 };\n\nThe way I read \"6.7.8 Initialization\" (sorry, I only have committee\ndraft wg14/n1124 of 2005 handy) is that\n\n\tstruct patch patch = { 0 };\n\nhas an initializer for a structure with an automatic storage\nduration, and for each of the subsequent fields of the structure\n(i.e. we ran out the initializer after dealing with that single zero\nthat talks about the first field), due to \"all subobjects that are\nnot initialized explicitly shall be initialized implicitly the same\nas objects that have static storage duration.\" rule, \"if it has a\npointer type, it is initialized to a null pointer\", which is exactly\nin line with your (and our) position that the first example I left\nin the above (new_name gets assigned NULL). So we are fine with the\nfields that are not speled out.\n\nBut then what about the explicitly spelled out 0 for the first\nfield? It is like an assignment, so by arguing that we should have\n0 over there and not NULL, you are essentially arguing for\n\n\tpatch.new_name = 0; /* not NULL */\n\naren't you?\n\nAs already pointed out downthread, sparse will catch an\ninitialization for an arithmetic type that is left to be NULL, but\nwhich should have been spelled 0, when fields are reordered anyway,\nso I do not think your \"only when initializing the first field of\nthe structure with a zero value while leaving the initializer for\nthe remainder unspelled, we should say 0 not NULL even when the\nfield has pointer type\" stance is not maintainable.\n\nAnd I agree with you that the calloc()/memset() that fills it with\n0-bit pattern is \"evil-doing\" as you say. Compared to that, the\ninitialization rule for objects with static storage duration is\nquite sane---a pointer field gets a NULL pointer and arithmetic\nfield gets a (positive or unsigned) zero.\n\nI wish if we could say\n\n\tstruct patch patch = {};\n\nso that we an leave all fields to have their natural zero value like\nfields in a static variable without explicit initialization do ;-)\nbut according to \"6.7.8 Initialization / Syntax #1\", the\ninitializer-list inside the braces must have at least one\ninitializer, so that won't be possible X-<.\n\n"},{"id":"378922","messageId":"CAPUEspgD8E02FcNvBx96neGEejdqMDWoH8NgpsHyGPo_KM09FA@mail.gmail.com","threadId":"51471","inReplyTo":"xmqq1rytpqse.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH] range-diff: fix some 'hdr-check' and sparse warnings","fromName":"Carlo Arenas","fromEmail":"carenas@gmail.com","sentAt":"2019-07-13T22:22:03Z","receivedAt":"2019-07-13T22:22:18Z","isPatch":true,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Sat, Jul 13, 2019 at 2:29 PM Junio C Hamano wrote:\n>\n> I wish if we could say\n>\n> struct patch patch = {};\n\nthat is actually a GNU extension that is supported by gcc and clang (at least)\nand that sparse also recognizes as valid; it is also valid C++ so it might be\neven supported by MSVC.\n\nit will obviously trigger warnings if using pedantic mode and is IMHO not worth\nthe hassle to maintain in a portable codebase like git, but also wish could be\nadded to C2X\n\nCarlo\n"},{"id":"378923","messageId":"20190714005129.GA4525@sigill.intra.peff.net","threadId":"51471","inReplyTo":"CAPUEspgD8E02FcNvBx96neGEejdqMDWoH8NgpsHyGPo_KM09FA@mail.gmail.com","subject":"Re: [PATCH] range-diff: fix some 'hdr-check' and sparse warnings","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-07-14T00:51:29Z","receivedAt":"2019-07-14T00:57:13Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jul 13, 2019 at 03:22:03PM -0700, Carlo Arenas wrote:\n\n> On Sat, Jul 13, 2019 at 2:29 PM Junio C Hamano wrote:\n> >\n> > I wish if we could say\n> >\n> > struct patch patch = {};\n> \n> that is actually a GNU extension that is supported by gcc and clang (at least)\n> and that sparse also recognizes as valid; it is also valid C++ so it might be\n> even supported by MSVC.\n> \n> it will obviously trigger warnings if using pedantic mode and is IMHO not worth\n> the hassle to maintain in a portable codebase like git, but also wish could be\n> added to C2X\n\nI wonder if we could come up with a definition of INIT_ZERO such that:\n\n struct foo bar = { INIT_ZERO };\n\nworked everywhere. IMHO that is more readable than \"{}\" anyway. In\nGNU-compatible compilers, it is just:\n\n #define INIT_ZERO\n\nUnfortunately I can't think of a fallback that would work universally.\nIt cannot just be \"0\", as we run into the NULL thing (not to mention\nwhen the first member is itself a struct). It does not help us to\nadd an explicit cast, because the type of the cast is dependent on the\ncontext in which the macro is used. Nor do I think typeof() could save\nus (if we could even assume it exists everywhere we need the fallback,\nwhich we almost certainly can't).\n\nBut it does seem a real shame there is no way to say \"zero-initialize\nthis struct\" in C without providing at least a single member value.\nOrdering struct definitions to put an arithmetic type at the start is an\nOK workaround (to just let \"0\" work everywhere). But it does fall down\nwhen the first element _has_ to be a struct (like, say, any user of our\nhashmap.[ch] interface).\n\n-Peff\n"},{"id":"378927","messageId":"9d6c7595-e320-7fa2-1f02-2f078b3831fa@kdbg.org","threadId":"51471","inReplyTo":"xmqq1rytpqse.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH] range-diff: fix some 'hdr-check' and sparse warnings","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2019-07-14T08:15:26Z","receivedAt":"2019-07-14T08:15:31Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 13.07.19 um 23:29 schrieb Junio C Hamano:\n> I do not think this position is maintainable, especially if you\n> agree with me (and everybody else, including sparse) that this is a\n> bad idea:\n> \n>> struct string_list dup_it = { 0, 0, 0, 1, 0 };\n> \n> The way I read \"6.7.8 Initialization\" (sorry, I only have committee\n> draft wg14/n1124 of 2005 handy) is that\n> \n> \tstruct patch patch = { 0 };\n> \n> has an initializer for a structure with an automatic storage\n> duration, and for each of the subsequent fields of the structure\n> (i.e. we ran out the initializer after dealing with that single zero\n> that talks about the first field), due to \"all subobjects that are\n> not initialized explicitly shall be initialized implicitly the same\n> as objects that have static storage duration.\" rule, \"if it has a\n> pointer type, it is initialized to a null pointer\", which is exactly\n> in line with your (and our) position that the first example I left\n> in the above (new_name gets assigned NULL). So we are fine with the\n> fields that are not speled out.\n> \n> But then what about the explicitly spelled out 0 for the first\n> field?\n\nYou are putting too much meaning in the token '0' when it appears in the\ntoken sequence '= { 0 }'. I understand this sequence as a signal to the\nreader of the code that \"the whole struct is to be zero-initialized\".\nNOT \"the first member is set to zero and everything else the default\nzero value\".\n\nIt just so happens that the compiler does the right thing with that '0'\nregardless of what type the first member has. (It even works when it is\na struct, Peff!) That zero is a null pointer constant if the first\nmember happens to be a pointer, i.e., the same value that is used for\nall other implicitly zero-initialized pointers.\n\n> It is like an assignment, so by arguing that we should have\n> 0 over there and not NULL, you are essentially arguing for\n> \n> \tpatch.new_name = 0; /* not NULL */\n> \n> aren't you?\n\nNo,no. You are stretching my argument too far. I really only mean the\nsequence = { 0 } as a signal. When this form of zero-initialization\nbecomes established, it takes away mental burden from the reader. It\nneed not be decomposed into its parts; there is no question of what is\nit that is initialized by '0', and what happens to the rest of the\nstruct. It means \"zero, all of it\" without thinking.\n\n> I wish if we could say\n> \n> \tstruct patch patch = {};\n> \n> so that we an leave all fields to have their natural zero value\n\nYES!\n\n-- Hannes\n"},{"id":"378928","messageId":"54c2ee44-ee99-ea4a-3154-f642e0060877@kdbg.org","threadId":"51471","inReplyTo":"20190714005129.GA4525@sigill.intra.peff.net","subject":"Re: [PATCH] range-diff: fix some 'hdr-check' and sparse warnings","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2019-07-14T08:30:27Z","receivedAt":"2019-07-14T08:30:31Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 14.07.19 um 02:51 schrieb Jeff King:\n> I wonder if we could come up with a definition of INIT_ZERO such that:\n> \n> struct foo bar = { INIT_ZERO };\n> \n> worked everywhere. IMHO that is more readable than \"{}\" anyway.\n\nNot when = {} becomes a well-established way to express\nzero-initialization. At that point, your suggested macro would obfuscate\nthe construct.\n\n> But it does seem a real shame there is no way to say \"zero-initialize\n> this struct\" in C without providing at least a single member value.\n\nIndeed. For this reason, I'm arguing for the second-best form that\nplaces a 0 between the braces.\n\n> Ordering struct definitions to put an arithmetic type at the start is an\n> OK workaround (to just let \"0\" work everywhere).\nWhy would you re-order members? There's nothing wrong when a pointer is\ninitialized by 0.\n\n> But it does fall down\n> when the first element _has_ to be a struct (like, say, any user of our\n> hashmap.[ch] interface).\n\nNo, it does not. It is not necessary to spell out nested structs in the\ninitializer.\n\n-- Hannes\n"},{"id":"378944","messageId":"nycvar.QRO.7.76.6.1907151647110.47@tvgsbejvaqbjf.bet","threadId":"51471","inReplyTo":"CAPUEspgD8E02FcNvBx96neGEejdqMDWoH8NgpsHyGPo_KM09FA@mail.gmail.com","subject":"Re: [PATCH] range-diff: fix some 'hdr-check' and sparse warnings","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-07-15T14:47:32Z","receivedAt":"2019-07-15T14:49:32Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\n\nOn Sat, 13 Jul 2019, Carlo Arenas wrote:\n\n> On Sat, Jul 13, 2019 at 2:29 PM Junio C Hamano wrote:\n> >\n> > I wish if we could say\n> >\n> > struct patch patch = {};\n>\n> that is actually a GNU extension that is supported by gcc and clang (at least)\n> and that sparse also recognizes as valid; it is also valid C++ so it might be\n> even supported by MSVC.\n\nIt seems to be supported by MSVC, at least as of VS2019.\n\nCiao,\nDscho\n"},{"id":"378945","messageId":"20190715144602.GA26636@sigill.intra.peff.net","threadId":"51471","inReplyTo":"54c2ee44-ee99-ea4a-3154-f642e0060877@kdbg.org","subject":"Re: [PATCH] range-diff: fix some 'hdr-check' and sparse warnings","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-07-15T14:46:03Z","receivedAt":"2019-07-15T14:50:35Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jul 14, 2019 at 10:30:27AM +0200, Johannes Sixt wrote:\n\n> Why would you re-order members? There's nothing wrong when a pointer is\n> initialized by 0.\n\nTo appease tooling like \"sparse\" without having to remember to do\nanything specific at the point-of-use sites. I'm open to the idea that\nit is not worth appeasing sparse, but this may be a simple and practical\ncompromise.\n\n> > But it does fall down\n> > when the first element _has_ to be a struct (like, say, any user of our\n> > hashmap.[ch] interface).\n> \n> No, it does not. It is not necessary to spell out nested structs in the\n> initializer.\n\nAh, that is news to me. I know that this compiles OK with \"gcc -Wall\",\nbut is it guaranteed by the standard?\n\n-- >8 --\n#include \n\nstruct outer {\n\tstruct {\n\t\tint x;\n\t\tchar *y;\n\t} inner;\n};\n\nint main(void)\n{\n\tstruct outer foo = { 0 };\n\tprintf(\"%d %p\\n\", foo.inner.x, foo.inner.y);\n\treturn 0;\n}\n-- 8< --\n\nIf so, then I agree that \"0\" is a pretty good solution, tooling like\n\"sparse\" aside. I do agree with your sentiment that \"0\" can be read as\n\"please zero-initialize this struct\" and not really as an attempt to set\nan initial member pointer to zero.\n\n-Peff\n"},{"id":"378948","messageId":"4be7a0a1-0256-40c3-4abc-d3d9302f527b@kdbg.org","threadId":"51471","inReplyTo":"20190715144602.GA26636@sigill.intra.peff.net","subject":"Re: [PATCH] range-diff: fix some 'hdr-check' and sparse warnings","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2019-07-15T17:30:09Z","receivedAt":"2019-07-15T17:30:22Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 15.07.19 um 16:46 schrieb Jeff King:\n> On Sun, Jul 14, 2019 at 10:30:27AM +0200, Johannes Sixt wrote:\n>>> But it does fall down\n>>> when the first element _has_ to be a struct (like, say, any user of our\n>>> hashmap.[ch] interface).\n>>\n>> No, it does not. It is not necessary to spell out nested structs in the\n>> initializer.\n> \n> Ah, that is news to me. I know that this compiles OK with \"gcc -Wall\",\n> but is it guaranteed by the standard?\n\nYes; see http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf,\n6.7.8 §20, in particular, the sentence beginning with \"Otherwise\".\n\n-- Hannes\n"},{"id":"378951","messageId":"20190715181527.GA30747@sigill.intra.peff.net","threadId":"51471","inReplyTo":"4be7a0a1-0256-40c3-4abc-d3d9302f527b@kdbg.org","subject":"Re: [PATCH] range-diff: fix some 'hdr-check' and sparse warnings","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-07-15T18:15:27Z","receivedAt":"2019-07-15T18:15:31Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jul 15, 2019 at 07:30:09PM +0200, Johannes Sixt wrote:\n\n> Am 15.07.19 um 16:46 schrieb Jeff King:\n> > On Sun, Jul 14, 2019 at 10:30:27AM +0200, Johannes Sixt wrote:\n> >>> But it does fall down\n> >>> when the first element _has_ to be a struct (like, say, any user of our\n> >>> hashmap.[ch] interface).\n> >>\n> >> No, it does not. It is not necessary to spell out nested structs in the\n> >> initializer.\n> > \n> > Ah, that is news to me. I know that this compiles OK with \"gcc -Wall\",\n> > but is it guaranteed by the standard?\n> \n> Yes; see http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf,\n> 6.7.8 §20, in particular, the sentence beginning with \"Otherwise\".\n\nThanks, I didn't know about that subtlety.\n\nI think relying on that flattening would be a terrible style choice to\nuse for initializing to particular values, but it makes perfect sense in\nthe context of using a single 0 to mean \"zero-initialize the whole\nstruct\".\n\nThat actually kind of makes me think that reordering our struct members\n(to put an arithmetic type or a struct containing one at the beginning)\n_might_ be worth doing as a workaround to tools like sparse. It's hacky,\nbut it puts the effort of dealing with this problem only in one spot\n(the struct definition) instead of many (everywhere the struct is used).\n\nBut I'd be happy if we could address it in another way (e.g., convincing\nsparse to stop complaining about it, or just decide it's not worth\ndealing with). One other thing I haven't seen discussed in this thread:\nwe could actually make our preferred style be for all structs to define\na FOO_INIT initializer, like we already do for STRBUF_INIT, etc. That's\na much more heavyweight solution than what's being discussed here, but\nit comes with an extra benefit: it's easy to catch and change all users\nif the struct switches away from zero-initialization.\n\nI'm on the fence on whether having non-zero initializers is a good\nstrategy overall. You can always bootstrap any other on-demand setup\nfrom the zero-initialized state, but it does sometimes lead to more\nawkward code (e.g., needing an explicit call to initialized_if_needed()\nin every function that works with the struct, or inverting the sense of\nboolean members so that the default is always \"0\").\n\n-Peff\n"},{"id":"378988","messageId":"xmqqo91t3itl.fsf@gitster-ct.c.googlers.com","threadId":"51471","inReplyTo":"20190715181527.GA30747@sigill.intra.peff.net","subject":"Re: [PATCH] range-diff: fix some 'hdr-check' and sparse warnings","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-07-16T19:01:10Z","receivedAt":"2019-07-16T19:01:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> But I'd be happy if we could address it in another way (e.g., convincing\n> sparse to stop complaining about it, or just decide it's not worth\n> dealing with). One other thing I haven't seen discussed in this thread:\n> we could actually make our preferred style be for all structs to define\n> a FOO_INIT initializer, like we already do for STRBUF_INIT, etc. That's\n> a much more heavyweight solution than what's being discussed here, but\n> it comes with an extra benefit: it's easy to catch and change all users\n> if the struct switches away from zero-initialization.\n\nI'd rather not to go that route. When we say\n\n\tstatic struct foo foo;\n\nwe are happy with the natural and trivial zero initialization of the\nstructure. If we didn't have to say STRBUF_INIT, the codebase would\nhave been a lot nicer with less noise. Because the implementation of\nthe strbuf cannot take the trivial zero initialized state as a valid\none, we had to sprinkle \" = STRBUF_INIT;\" all over.\n\nAnd that \"quiet and nice\" form is a moral equivalent of\n\n\tstruct foo foo = { 0 };\n\nthat has been discussed in this thread. I'd rather not to see it\nturned into distinct FOO_INIT, BAR_INIT, etc. to force the reader to\nthink these structures all need their specific initialization and\nwonder what's the reason for each of them.\n\nOne universal \"struct foo foo = STRUCT_ZERO_INIT;\" that is applied\nto all kinds of structure I could live with (but only if we have a\ngood way to squelch sparse from bitching about it). Perhaps we\ncould define it as \"{}\" for GCC, while keeping it \"{ 0 }\" for\nothers. As I said, { 0 } is undefensible if we insist that a null\npointer must be spelled NULL and not 0 (as CodingGuidelines says),\nbut as long as we declare that we take \"{ 0 }\" as a mere convention\n(like we used to use the \"int foo = foo;\" convention to squelch\n\"uninitialized but used\" warnings) that is outside the purview of\nlanguage-lawyers, I am perfectly fine with it, and if it is hidden\nbehind a macro, that would be even better ;-)\n\n\n\n"},{"id":"378991","messageId":"20190716200101.GA6558@sigill.intra.peff.net","threadId":"51471","inReplyTo":"xmqqo91t3itl.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH] range-diff: fix some 'hdr-check' and sparse warnings","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-07-16T20:01:01Z","receivedAt":"2019-07-16T20:01:04Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jul 16, 2019 at 12:01:10PM -0700, Junio C Hamano wrote:\n\n> And that \"quiet and nice\" form is a moral equivalent of\n> \n> \tstruct foo foo = { 0 };\n> \n> that has been discussed in this thread. I'd rather not to see it\n> turned into distinct FOO_INIT, BAR_INIT, etc. to force the reader to\n> think these structures all need their specific initialization and\n> wonder what's the reason for each of them.\n\nI'm on the fence for that style myself. But we've definitely been\ntrending in that direction. Look at `git grep _INIT *.h`, many of which\nare clearly zero-initializers.\n\nI do think it's nice to be able to modify the initializers later and\nfeel confident that you're catching all of the users. But even then:\n\n - it's not like we get any kind of static warning for a\n zero-initialized variant (be it static or with a manual {0}\n initializer)\n\n - I know I've run into problems where code assumed memset() worked,\n but it didn't (I think diff_options was one such case).\n\nSo at best it's \"feel more confident\", not \"feel confident\". :)\n\n> One universal \"struct foo foo = STRUCT_ZERO_INIT;\" that is applied\n> to all kinds of structure I could live with (but only if we have a\n> good way to squelch sparse from bitching about it). Perhaps we\n> could define it as \"{}\" for GCC, while keeping it \"{ 0 }\" for\n> others. As I said, { 0 } is undefensible if we insist that a null\n> pointer must be spelled NULL and not 0 (as CodingGuidelines says),\n> but as long as we declare that we take \"{ 0 }\" as a mere convention\n> (like we used to use the \"int foo = foo;\" convention to squelch\n> \"uninitialized but used\" warnings) that is outside the purview of\n> language-lawyers, I am perfectly fine with it, and if it is hidden\n> behind a macro, that would be even better ;-)\n\nYeah, I am OK with that. My big question is if we use \"{}\" for gcc (and\ncompatible friends), does that squelch all of the complaints from other\ncompilers and tools that might see the \"{0}\" version? In particular,\ndoes it work for sparse?\n\n-Peff\n"},{"id":"379024","messageId":"a6af2961-3f09-5d8a-b92b-c50e6877ec81@kdbg.org","threadId":"51471","inReplyTo":"xmqqo91t3itl.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH] range-diff: fix some 'hdr-check' and sparse warnings","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2019-07-17T17:23:16Z","receivedAt":"2019-07-17T17:23:20Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 16.07.19 um 21:01 schrieb Junio C Hamano:\n> but as long as we declare that we take \"{ 0 }\" as a mere convention\n> [...], I am perfectly fine with it, and if it is hidden\n> behind a macro, that would be even better ;-)\n\nAnd I thought that \"Avoid macros!\" would be a welcome guideline...\n\nI think we enter subjective territory. Let's stop here.\n\n-- Hannes\n"},{"id":"379026","messageId":"xmqq1ryo1qdr.fsf@gitster-ct.c.googlers.com","threadId":"51471","inReplyTo":"20190716200101.GA6558@sigill.intra.peff.net","subject":"Re: [PATCH] range-diff: fix some 'hdr-check' and sparse warnings","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-07-17T18:13:04Z","receivedAt":"2019-07-17T18:13:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> ... My big question is if we use \"{}\" for gcc (and\n> compatible friends), does that squelch all of the complaints from other\n> compilers and tools that might see the \"{0}\" version? In particular,\n> does it work for sparse?\n\nYeah, I agree that it is the most important question. The best\nsolution is not to do the macro, use \"= { 0 };\" everywhere *and*\nsomehow arrange sparse not to complain about it. I am not sure if\nthe last part is doable, though.\n"},{"id":"379028","messageId":"20190717192121.GA5447@sigill.intra.peff.net","threadId":"51471","inReplyTo":"xmqq1ryo1qdr.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH] range-diff: fix some 'hdr-check' and sparse warnings","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-07-17T19:21:21Z","receivedAt":"2019-07-17T19:21:25Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jul 17, 2019 at 11:13:04AM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > ... My big question is if we use \"{}\" for gcc (and\n> > compatible friends), does that squelch all of the complaints from other\n> > compilers and tools that might see the \"{0}\" version? In particular,\n> > does it work for sparse?\n> \n> Yeah, I agree that it is the most important question. The best\n> solution is not to do the macro, use \"= { 0 };\" everywhere *and*\n> somehow arrange sparse not to complain about it. I am not sure if\n> the last part is doable, though.\n\nI did just check \"make range-diff.sp\" with this diff:\n\ndiff --git a/range-diff.c b/range-diff.c\nindex ba1e9a4265..481cefff3e 100644\n--- a/range-diff.c\n+++ b/range-diff.c\n@@ -102,7 +102,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 = { };\n \t\t\tstruct strbuf root = STRBUF_INIT;\n \t\t\tint linenr = 0;\n \n\nand it seems OK. So presumably we could just lump sparse into the list\nof gcc-compatible platforms, and it would work. But it does require the\nmacro still for other hosts.\n\nOther than that, our options seem to be:\n\n 1. Live with it. IIRC we're already not sparse-clean, and Ramsay\n mostly looks at the diff to find new problems.\n\n 2. Pass -Wno-non-pointer-null to sparse. Unfortunately that also\n disables more useful warnings (like passing \"0\" instead of NULL to\n a function).\n\n 3. Switch to NULL here, and adhere to that going forward.\n\n-Peff\n"},{"id":"379029","messageId":"xmqqmuhczakk.fsf@gitster-ct.c.googlers.com","threadId":"51471","inReplyTo":"20190717192121.GA5447@sigill.intra.peff.net","subject":"Re: [PATCH] range-diff: fix some 'hdr-check' and sparse warnings","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-07-17T20:10:35Z","receivedAt":"2019-07-17T20:10:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Other than that, our options seem to be:\n>\n> 1. Live with it. IIRC we're already not sparse-clean, and Ramsay\n> mostly looks at the diff to find new problems.\n\nOK.\n\n> 2. Pass -Wno-non-pointer-null to sparse. Unfortunately that also\n> disables more useful warnings (like passing \"0\" instead of NULL to\n> a function).\n\nNon starter, I am afraind. The loss outweighs.\n\n> 3. Switch to NULL here, and adhere to that going forward.\n\nThis does not sound too bad.\n"},{"id":"406830","messageId":"xmqq4knca7c6.fsf@gitster.c.googlers.com","threadId":"51471","inReplyTo":"nycvar.QRO.7.76.6.1907151647110.47@tvgsbejvaqbjf.bet","subject":"Re: [PATCH] range-diff: fix some 'hdr-check' and sparse warnings","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-10-02T17:03:21Z","receivedAt":"2020-10-02T17:03:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Sat, 13 Jul 2019, Carlo Arenas wrote:\n>\n>> On Sat, Jul 13, 2019 at 2:29 PM Junio C Hamano wrote:\n>> >\n>> > I wish if we could say\n>> >\n>> > struct patch patch = {};\n>>\n>> that is actually a GNU extension that is supported by gcc and clang (at least)\n>> and that sparse also recognizes as valid; it is also valid C++ so it might be\n>> even supported by MSVC.\n>\n> It seems to be supported by MSVC, at least as of VS2019.\n\nIn on Fri, 2\nOct 2020 15:57:45 +0200 (CEST), it was said:\n\n> Before you further split it up, I encourage you to include these patches\n> without which the CI builds will continue to fail (Junio, could I ask you\n> to either cherry-pick them from https://github.com/git-for-windows/git's\n> shears/seen branch, or apply them from the mbox?):\n>\n> -- snipsnap --\n> From e485e006f34922439f2e971a1c5c38b8ca56c011 Mon Sep 17 00:00:00 2001\n> From: Johannes Schindelin \n> Date: Wed, 30 Sep 2020 14:46:59 +0200\n> Subject: [PATCH 1/3] fixup??? reftable: rest of library\n>\n> \tstruct abc x = {}\n>\n> is a GNUism.\n\nPerhaps VS2020 no longer allows it?\n\n;-)\n\nJokes aside, I think we agreed in that old thread I am responding to\nthat \"= { 0 }\" was the way to go, so let's keep doing so.\n\nThanks.\n"},{"id":"406937","messageId":"nycvar.QRO.7.76.6.2010042034220.50@tvgsbejvaqbjf.bet","threadId":"51471","inReplyTo":"xmqq4knca7c6.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] range-diff: fix some 'hdr-check' and sparse warnings","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2020-10-04T18:35:16Z","receivedAt":"2020-10-05T12:25:44Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Fri, 2 Oct 2020, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n>\n> > On Sat, 13 Jul 2019, Carlo Arenas wrote:\n> >\n> >> On Sat, Jul 13, 2019 at 2:29 PM Junio C Hamano wrote:\n> >> >\n> >> > I wish if we could say\n> >> >\n> >> > struct patch patch = {};\n> >>\n> >> that is actually a GNU extension that is supported by gcc and clang (at least)\n> >> and that sparse also recognizes as valid; it is also valid C++ so it might be\n> >> even supported by MSVC.\n> >\n> > It seems to be supported by MSVC, at least as of VS2019.\n>\n> In on Fri, 2\n> Oct 2020 15:57:45 +0200 (CEST), it was said:\n>\n> > Before you further split it up, I encourage you to include these patches\n> > without which the CI builds will continue to fail (Junio, could I ask you\n> > to either cherry-pick them from https://github.com/git-for-windows/git's\n> > shears/seen branch, or apply them from the mbox?):\n> >\n> > -- snipsnap --\n> > From e485e006f34922439f2e971a1c5c38b8ca56c011 Mon Sep 17 00:00:00 2001\n> > From: Johannes Schindelin \n> > Date: Wed, 30 Sep 2020 14:46:59 +0200\n> > Subject: [PATCH 1/3] fixup??? reftable: rest of library\n> >\n> > \tstruct abc x = {}\n> >\n> > is a GNUism.\n>\n> Perhaps VS2020 no longer allows it?\n>\n> ;-)\n\nI suspect that it does allow it, but only when compiling C++, not when\ncompiling C. At least in my hands, it failed to compiler that construct.\n\n> Jokes aside, I think we agreed in that old thread I am responding to\n> that \"= { 0 }\" was the way to go, so let's keep doing so.\n\nYep, we're on the same page.\n\nCiao,\nDscho\n"}]}