Jeff King writes:
> Other than that, our options seem to be:
>
> 1. Live with it. IIRC we're already not sparse-clean, and Ramsay
> mostly looks at the diff to find new problems.
OK.
> 2. Pass -Wno-non-pointer-null to sparse. Unfortunately that also
> disables more useful warnings
On Wed, Jul 17, 2019 at 11:13:04AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > ... My big question is if we use "{}" for gcc (and
> > compatible friends), does that squelch all of the complaints from other
> > compilers and tools that might see the "{0}" version? In particular,
> > do
Jeff King writes:
> ... My big question is if we use "{}" for gcc (and
> compatible friends), does that squelch all of the complaints from other
> compilers and tools that might see the "{0}" version? In particular,
> does it work for sparse?
Yeah, I agree that it is the most important question.
Am 16.07.19 um 21:01 schrieb Junio C Hamano:
> but as long as we declare that we take "{ 0 }" as a mere convention
> [...], I am perfectly fine with it, and if it is hidden
> behind a macro, that would be even better ;-)
And I thought that "Avoid macros!" would be a welcome guideline...
I think w
On Tue, Jul 16, 2019 at 12:01:10PM -0700, Junio C Hamano wrote:
> And that "quiet and nice" form is a moral equivalent of
>
> struct foo foo = { 0 };
>
> that has been discussed in this thread. I'd rather not to see it
> turned into distinct FOO_INIT, BAR_INIT, etc. to force the reader to
Jeff King writes:
> But I'd be happy if we could address it in another way (e.g., convincing
> sparse to stop complaining about it, or just decide it's not worth
> dealing with). One other thing I haven't seen discussed in this thread:
> we could actually make our preferred style be for all struc
On Mon, Jul 15, 2019 at 07:30:09PM +0200, Johannes Sixt wrote:
> Am 15.07.19 um 16:46 schrieb Jeff King:
> > On Sun, Jul 14, 2019 at 10:30:27AM +0200, Johannes Sixt wrote:
> >>> But it does fall down
> >>> when the first element _has_ to be a struct (like, say, any user of our
> >>> hashmap.[ch] i
Am 15.07.19 um 16:46 schrieb Jeff King:
> On Sun, Jul 14, 2019 at 10:30:27AM +0200, Johannes Sixt wrote:
>>> But it does fall down
>>> when the first element _has_ to be a struct (like, say, any user of our
>>> hashmap.[ch] interface).
>>
>> No, it does not. It is not necessary to spell out nested
On Sun, Jul 14, 2019 at 10:30:27AM +0200, Johannes Sixt wrote:
> Why would you re-order members? There's nothing wrong when a pointer is
> initialized by 0.
To appease tooling like "sparse" without having to remember to do
anything specific at the point-of-use sites. I'm open to the idea that
it
Hi,
On Sat, 13 Jul 2019, Carlo Arenas wrote:
> On Sat, Jul 13, 2019 at 2:29 PM Junio C Hamano wrote:
> >
> > I wish if we could say
> >
> > struct patch patch = {};
>
> that is actually a GNU extension that is supported by gcc and clang (at least)
> and that sparse also recognizes as va
Am 14.07.19 um 02:51 schrieb Jeff King:
> I wonder if we could come up with a definition of INIT_ZERO such that:
>
> struct foo bar = { INIT_ZERO };
>
> worked everywhere. IMHO that is more readable than "{}" anyway.
Not when = {} becomes a well-established way to express
zero-initialization.
Am 13.07.19 um 23:29 schrieb Junio C Hamano:
> 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,
On Sat, Jul 13, 2019 at 03:22:03PM -0700, Carlo Arenas wrote:
> On Sat, Jul 13, 2019 at 2:29 PM Junio C Hamano wrote:
> >
> > I wish if we could say
> >
> > struct patch patch = {};
>
> that is actually a GNU extension that is supported by gcc and clang (at least)
> and that sparse also
On Sat, Jul 13, 2019 at 2:29 PM Junio C Hamano wrote:
>
> I wish if we could say
>
> struct patch patch = {};
that is actually a GNU extension that is supported by gcc and clang (at least)
and that sparse also recognizes as valid; it is also valid C++ so it might be
even supported by MSVC
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 tr
On Sat, Jul 13, 2019 at 3:46 AM Johannes Sixt wrote:
>
> Using only = { 0 } for zero-initialization makes the code immune to
> rearrangements of the struct members.
But only by forcing to set whichever is the first element to 0, which is
exactly what sparse is complaining about, since it happens
Am 13.07.19 um 12:44 schrieb Johannes Sixt:
> Am 12.07.19 um 18:44 schrieb Junio C Hamano:
>> Johannes Sixt 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
Am 12.07.19 um 18:44 schrieb Junio C Hamano:
> Johannes Sixt 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(c
Johannes Sixt 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)
>>
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)
> }
>
> i
Signed-off-by: Ramsay Jones
---
Hi Thomas,
If you need to re-roll your 'tg/range-diff-output-update' branch, could
you please squash (parts) of this into the relevant patches.
The first hunk fixes a couple of 'hdr-check' warnings:
$ diff nhcout phcout | head
4a5,13
> apply.h:146:22: er
21 matches
Mail list logo
