From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lukasz Majewski Date: Mon, 24 Nov 2014 09:39:45 +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: <20141124093945.54847988@amdc2363> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Albert, > 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 will check the exact gcc on my office PC tomorrow. On my office PC I've got following gcc: Using built-in specs. COLLECT_GCC=gcc 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 I've got a stable debian (Wheezy - 7.4) > > > Heiko also complained about this Warning. Heiko could you also share > information about your setup? > > > > > > > Regards, > > > > Jeroen > > > > > > Best regards, > > > Lukasz Majewski > > > > Amicalement, > > Best regards, > Lukasz Majewski -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group