Re: /* compiler workaround */ - what was the issue?
- From
Philip Oakley <philipoakley@iee.org>
- Date
- May 6, 2016, 13:15 UTC
- Message-ID
- <51C902B1F7464CF2B58EB0E495F86BB5@PhilipOakley>
- In-Reply-To
- <CACsJy8CBuU8H8r_f4KsnLkhLtfRv0nDo4hGS31LVn0e1Y_3OAQ@mail.gmail.com>
From: "Duy Nguyen" <pclouds@gmail.com>
Show 29 quoted lines
> On Fri, May 6, 2016 at 4:41 AM, Junio C Hamano <gitster@pobox.com> wrote: >> "Philip Oakley" <philipoakley@iee.org> writes: >> >>> int saved_namelen = saved_namelen; /* compiler workaround */ >>> >>> Which then becomes an MSVC compile warning C4700: uninitialized local >>> variable. >>> >>> I'm wondering what was the compiler workaround being referred to? i.e. >>> why >>> does it need that tweak? There's no mention of the reason in the commit >>> message. >> >> That was a fairly well-known workaround for GCC that issues a false >> warning that variable is used before initialized. I thought we >> stopped using it several years ago in new code after doing a bulk >> sanitizing > > I guess that's 803a777 (cat-file: Fix an gcc -Wuninitialized warning - > 2013-03-26) and more commits around that time. The split-index commit > is in 2014. I must have missed the trend. > >> (I think the new recommended workaround was to initialise >> such a variable to the nil value like '0' for integers). > > Yep. First Jeff removed the " = xxx" part from "xxx = xxx" then Ramsay > added the " = NULL" back. So we probably just do "int saved_namelen = > 0;" in this case. > --
Thanks,
I'll try and work up a patch - probably next week as I'm away for the weekend.
-- Philip