list mirror (unofficial, one of many)
 help / color / Atom feed
From: Junio C Hamano <>
To: Johannes Sixt <>
Cc: Ramsay Jones <>,
	Thomas Gummerer <>,
	GIT Mailing-list <>
Subject: Re: [PATCH] range-diff: fix some 'hdr-check' and sparse warnings
Date: Sat, 13 Jul 2019 14:29:05 -0700
Message-ID: <> (raw)
In-Reply-To: <>

Johannes Sixt <> writes:

>> 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.

I do not think this position is maintainable, especially if you
agree with me (and everybody else, including sparse) that this is a
bad idea:

>   struct string_list dup_it = { 0, 0, 0, 1, 0 };

The way I read "6.7.8 Initialization" (sorry, I only have committee
draft wg14/n1124 of 2005 handy) is that

	struct patch patch = { 0 };

has an initializer for a structure with an automatic storage
duration, and for each of the subsequent fields of the structure
(i.e. we ran out the initializer after dealing with that single zero
that talks about the first field), due to "all subobjects that are
not initialized explicitly shall be initialized implicitly the same
as objects that have static storage duration." rule, "if it has a
pointer type, it is initialized to a null pointer", which is exactly
in line with your (and our) position that the first example I left
in the above (new_name gets assigned NULL).  So we are fine with the
fields that are not speled out.

But then what about the explicitly spelled out 0 for the first
field?  It is like an assignment, so by arguing that we should have
0 over there and not NULL, you are essentially arguing for

	patch.new_name = 0; /* not NULL */

aren't you?

As already pointed out downthread, sparse will catch an
initialization for an arithmetic type that is left to be NULL, but
which should have been spelled 0, when fields are reordered anyway,
so I do not think your "only when initializing the first field of
the structure with a zero value while leaving the initializer for
the remainder unspelled, we should say 0 not NULL even when the
field has pointer type" stance is not maintainable.

And I agree with you that the calloc()/memset() that fills it with
0-bit pattern is "evil-doing" as you say.  Compared to that, the
initialization rule for objects with static storage duration is
quite sane---a pointer field gets a NULL pointer and arithmetic
field gets a (positive or unsigned) zero.

I wish if we could say

	struct patch patch = {};

so that we an leave all fields to have their natural zero value like
fields in a static variable without explicit initialization do ;-)
but according to "6.7.8 Initialization / Syntax #1", the
initializer-list inside the braces must have at least one
initializer, so that won't be possible X-<.

  parent reply index

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-11 22:03 Ramsay Jones
2019-07-12  5:21 ` Johannes Sixt
2019-07-12 16:44   ` Junio C Hamano
2019-07-13 10:44     ` Johannes Sixt
2019-07-13 12:18       ` Johannes Sixt
2019-07-13 12:56       ` Carlo Arenas
2019-07-13 21:29       ` Junio C Hamano [this message]
2019-07-13 22:22         ` Carlo Arenas
2019-07-14  0:51           ` Jeff King
2019-07-14  8:30             ` Johannes Sixt
2019-07-15 14:46               ` Jeff King
2019-07-15 17:30                 ` Johannes Sixt
2019-07-15 18:15                   ` Jeff King
2019-07-16 19:01                     ` Junio C Hamano
2019-07-16 20:01                       ` Jeff King
2019-07-17 18:13                         ` Junio C Hamano
2019-07-17 19:21                           ` Jeff King
2019-07-17 20:10                             ` Junio C Hamano
2019-07-17 17:23                       ` Johannes Sixt
2019-07-15 14:47           ` Johannes Schindelin
2019-07-14  8:15         ` Johannes Sixt

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:

AGPL code for this site: git clone public-inbox