git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] range-diff: fix some 'hdr-check' and sparse warnings

From
Johannes Sixt <j6t@kdbg.org>
Date
Jul 13, 2019, 10:44 UTC
Message-ID
<ec635d0d-00ca-2419-3c1a-9b0343b46daa@kdbg.org>
In-Reply-To
<xmqqy313p5hn.fsf@gitster-ct.c.googlers.com>
Am 12.07.19 um 18:44 schrieb Junio C Hamano:
Show 28 quoted lines
> Johannes Sixt <j6t@kdbg.org> writes:
> 
>> Am 12.07.19 um 00:03 schrieb Ramsay Jones:
>>> diff --git a/range-diff.c b/range-diff.c
>>> index ba1e9a4265..0f24a4ad12 100644
>>> --- a/range-diff.c
>>> +++ b/range-diff.c
>>> @@ -102,7 +102,7 @@ static int read_patches(const char *range, struct string_list *list)
>>>  		}
>>>  
>>>  		if (starts_with(line, "diff --git")) {
>>> -			struct patch patch = { 0 };
>>> +			struct patch patch = { NULL };
>>
>> There is nothing wrong with 0 here. IMHO, zero-initialization should
>> *always* be written as = { 0 } and nothing else. Changing 0 to NULL to
>> pacify sparse encourages a wrong style.
> 
> Hmm, care to elaborate a bit?  Certainly, we have a clear preference
> between these two:
> 
> 	struct patch patch;
> 	patch.new_name = 0;
> 	patch.new_name = NULL;
> 
> where the "char *new_name" field is the first one in the structure.
> We always try to write the latter, even though we know they ought to
> be equivalent to the language lawyers.
I'm not questioning this case; the latter form is clearly preferable.

Using only = { 0 } for zero-initialization makes the code immune to rearrangements of the struct members. That is not the case with = { NULL } because it requires that the first member is a pointer; if rearrangement makes the first member a non-pointer, the initializations must be adjusted.

On the other hand, I'm not arguing that
  struct string_list dup_it = { NULL, 0, 0, 1, NULL };
should be written as
  struct string_list dup_it = { 0, 0, 0, 1, 0 };

I'm only complaining about the single-initializer = { 0 } "please initialize this whole struct with zero values" form.

Show 8 quoted lines
> Is the reason why you say 0 is fine here because we consider
> 
> 	struct patch patch, *dpatch;
> 	memset(&patch, 0, sizeof(patch));
> 	dpatch = xcalloc(1, sizeof(patch));
> 
> are perfectly good way to trivially iniitialize an instance of the
> struct?

Absolutely not. Both forms are evildoing as far as struct initialization is concerned because they ignore the types of the members. The memset form should always be replaced by = { 0 }. The correct replacement for the xcalloc form would be

	struct patch zero = { 0 };
	struct patch *dpatch = xmalloc(sizeof(*dpatch));
	*dpatch = zero;
but I do understand that this transformation is unacceptably verbose.
> Do we want to talk to sparse folks about this?

I've no idea which camp they are in. How would they respond to an exceptional case that is also very much a matter of taste?

-- Hannes
Previous: Junio C HamanoNext: Johannes Sixt
Message 4 of 23 in “range-diff: fix some 'hdr-check' and sparse warnings”
  1. range-diff: fix some 'hdr-check' and sparse warningsRamsay Jones, Jul 11, 2019
  2. Johannes SixtJul 12, 2019
  3. Junio C HamanoJul 12, 2019
  4. Johannes SixtJul 13, 2019
  5. Johannes SixtJul 13, 2019
  6. Carlo ArenasJul 13, 2019
  7. Junio C HamanoJul 13, 2019
  8. Carlo ArenasJul 13, 2019
  9. Jeff KingJul 14, 2019
  10. Johannes SixtJul 14, 2019
  11. Jeff KingJul 15, 2019
  12. Johannes SixtJul 15, 2019
  13. Jeff KingJul 15, 2019
  14. Junio C HamanoJul 16, 2019
  15. Jeff KingJul 16, 2019
  16. Junio C HamanoJul 17, 2019
  17. Jeff KingJul 17, 2019
  18. Junio C HamanoJul 17, 2019
  19. Johannes SixtJul 17, 2019
  20. Johannes SchindelinJul 15, 2019
  21. Junio C HamanoOct 2, 2020
  22. Johannes SchindelinOct 4, 2020
  23. Johannes SixtJul 14, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.