Re: fs/ntfscomp.c:82:11: error: ‘flg’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

From: Daniel Kiper <dkiper@net-space.pl>
To: PGNet Dev <pgnet.dev@gmail.com>
Cc: Michael Chang <mchang@suse.com>,
	The development of GNU GRUB <grub-devel@gnu.org>,
	pmenzel@molgen.mpg.de
Subject: Re: fs/ntfscomp.c:82:11: error: ‘flg’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
Date: Fri, 27 Mar 2020 15:45:19 +0100	[thread overview]
Message-ID: <20200327144519.cjmiftxrlaa47r4x@tomti.i.net-space.pl> (raw)
In-Reply-To: <7c3d6f54-acd2-46a4-7f16-8a79a8309b47@gmail.com>

On Thu, Mar 26, 2020 at 04:10:05AM -0700, PGNet Dev wrote:
> On 3/26/20 1:39 AM, Paul Menzel wrote:
>
> > I am unable to reproduce this with
>
> 1st sanity re-check:
>
>
>
> I _am_ able to reproduce this consistently, with same error.
>
>
>
> I've tested now on multiple machines; not identical, but all similarly opensuse + GCC10 dev envs ...
>
>
>
>
> > Here is the code in question:
>
> snip
>
> > Why is it complaining complaining in line 82 and not 78, where `flg` is already accessed?
>
> On 3/26/20 3:39 AM, Michael Chang wrote:
> > Looking into build log, the build option seems to have been overridden
> > with CFLAGS settings like this.
> >
> > CFLAGS="-O3 -Wall -fstack-protector-strong -funwind-tables
> > -fasynchronous-unwind-tables -fmessage-length=0 -grecord-gcc-switches
> > -march=native -mtune=native"
> >
> > I'm not sure if -O3 is considered as supported  since that will result
> > in larger binaries we are striving to reduce all the time. Also the
> > optimization it brings would require careful review if we don't enable
> > it by default.
> >
> > In addition, -fstack-protector-strong breaks the build even harder with
> > a lot of __stack_chk_fail undefined symbol in the modules.
> >
> > If going with default build option, I also don't have this compliation
> > error.
>
>
> indeed.
>
> building with
>
> 	unset CC CPP
> +	unset LD CFLAGS CPPFLAGS CXXFLAGS
>
> 	./bootstrap
> 	./autogen.sh
>
> 	./configure \
> 	--prefix=/usr/local/grub-build-test
>
> 	make V=1
>
> completes without error, and installs,
>
>
> 	/usr/local/grub-build-test/bin/grub-mkrescue --version
> 		/usr/local/grub-build-test/bin/grub-mkrescue (GRUB) 2.05
>
>
> which I can certainly manage easily enough for local build.
>
> > If going with default build option
>
> _is_ a 'clear' env expected/recommended/required for a grub2 build?

You control your own build environment. So, if you add options which are
not supported by the GRUB then there is pretty good chance that the
build or generated output will fall apart at some point. However, if you
think a given compiler option should be supported by the GRUB or even
used by default please provide a patch with good explanation why we
should take it.

> if so, does this need to be handled at config time?

I am not sure what do you mean by that.

Daniel