From mboxrd@z Thu Jan 1 00:00:00 1970 From: Guillaume Gardet Date: Mon, 24 Nov 2014 09:52:51 +0100 Subject: [U-Boot] [PATCH] fix: tools: kwbimage.c: Initialize headersz to suppress warning In-Reply-To: <20141123183815.56d68f90@jawa> References: <1416558163-23614-1-git-send-email-l.majewski@samsung.com> <20141121093514.5166e9fd@free-electrons.com> <20141121102026.75aad6e2@amdc2363> <546F3161.1040906@myspectrum.nl> <20141121163059.31b19f9f@lilith> <546F93D0.8040807@myspectrum.nl> <20141122075635.1ada8679@jawa> <20141122131718.3c278626@lilith> <20141123183815.56d68f90@jawa> Message-ID: <5472F1E3.7090101@free.fr> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi, Le 23/11/2014 18:38, Lukasz Majewski a ?crit : > Hi Albert, > > Sorry for a late reply. > >> Hello Lukasz, >> >> On Sat, 22 Nov 2014 07:56:35 +0100, Lukasz Majewski >> wrote: >> >>>> Agreed in general, but not for this one, since "fixing" is the >>>> carpet, >>> I assume that you are presenting below an answer to a "general" >>> case. >>> >>> However, as Thomas pointed out earlier, this "fix" is perfectly safe >>> regarding the underlying kwbimage code. >> Jeroen and I (full disclaimer: we have discussed the topic on IRC) >> do not contend that the proposed fix would be unsafe; it *is* safe, >> i.e. it does not adversely affect the code behavior in any measurable >> way. >> >> What we contend is that the fix be the /right/ fix (although Jeroen >> and I have slightly differing criteria for defining what "the right >> fix" would be). >> >>>>> and >>>>> the only justification I see as acceptable for doing so is when >>>>> leaving the warning enabled would cause an obnoxiously high >>>>> number of false positives. >>>> Well let me add, if "fixing the warning" causes real error >>>> to be hidden, we shouldn't "fix" the warnings by modifying >>>> valid code. >>> Each subsequent "fix" for this kind of warning should be considered >>> case by case IMHO, therefore I agree with Albert. >> Jeroen also agreed on IRC that disabling the compiler warning is not >> the right fix either; and I agreed that there had to be a better fix >> than pseudo-initializing headersz. I therefore suggested refactoring >> kwbimage_set_header in order to ensure gcc does not emit the warning, >> but without resorting to non-functional code such as a functionally >> meaningless initialization. >> >> Problem is, to refactor the code, one needs a gcc which emits the >> warnig. I tried various versions of gcc (4.7.4, 4.8.3, 4.9.1) and all >> remained silent when compiling tools/kwbimage.c. >> >> Hence my request: Lukasz, which toolchain are you using exactly? Where >> can we download it from? > The warning appear on my personal laptop too: > > lukma at jawa:~/work/embedded/u-boot-denx (master)$ cc -v > Using built-in specs. > COLLECT_GCC=cc > COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper > Target: x86_64-linux-gnu > Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' > --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs > --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr > --program-suffix=-4.7 --enable-shared --enable-linker-build-id > --with-system-zlib --libexecdir=/usr/lib --without-included-gettext > --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 > --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu > --enable-libstdcxx-debug --enable-libstdcxx-time=yes > --enable-gnu-unique-object --enable-plugin --enable-objc-gc > --with-arch-32=i586 --with-tune=generic --enable-checking=release > --build=x86_64-linux-gnu --host=x86_64-linux-gnu > --target=x86_64-linux-gnu Thread model: posix gcc version 4.7.2 (Debian > 4.7.2-5) > > > HOSTCC tools/kwbimage.o > tools/kwbimage.c: In function ?kwbimage_set_header?: > tools/kwbimage.c:803:8: warning: ?headersz? may be used uninitialized > in this function [-Wmaybe-uninitialized] > > Debian distro: version 7.6 (Wheezy) I also have this warning on my openSUSE 13.1 (GCC 4.8.1). If it could help, "gcc -v" returns: ********************************************************************** Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --program-suffix=-4.8 --enable-linux-futex --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.8.1 20130909 [gcc-4_8-branch revision 202388] (SUSE Linux) ********************************************************************** Guillaume