[Bug general/21011] New: "may be used uninitialized" error with -Werror=maybe-uninitialized

[Bug general/21011] New: "may be used uninitialized" error with -Werror=maybe-uninitialized

[luizluca at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21011

            Bug ID: 21011
           Summary: "may be used uninitialized" error with
                    -Werror=maybe-uninitialized
           Product: elfutils
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: general
          Assignee: unassigned at sourceware dot org
          Reporter: luizluca at gmail dot com
                CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

Hello,

I get this error when compiling with -Werror=maybe-uninitialized

elf_getarsym.c: In function 'elf_getarsym':
elf_getarsym.c:200:14: error: 'n' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
       size_t ar_sym_len = (n + 1) * sizeof (Elf_Arsym);


I know that read_number_entries define its values unconditionally but it won't
hurt to simply use:

  uint64_t n = 0;

Is it ok?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized

[luizluca at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21011

--- Comment #1 from Luiz Angelo Daros de Luca <luizluca at gmail dot com> ---
Another case:

i386_disasm.c: In function 'i386_disasm':
/home/luizluca/prog-local/lede/trunk/staging_dir/toolchain-mipsel_24kc_gcc-5.4.0_musl-1.1.15/include/fortify/string.h:47:24:
error: 'str' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
      (__s < __d && __s + __n > __d))

i386_disasm.c:709:17: note: 'str' was declared here
     const char *str;


This is because of missing:

--- a/libcpu/i386_disasm.c
+++ b/libcpu/i386_disasm.c
@@ -822,6 +822,7 @@ i386_disasm (Ebl *ebl __attribute__((unu
              /* Fallthrough */
            default:
              assert (! "INVALID not handled");
+             str = "";
            }
            }
          else

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized

[pmachata at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21011

--- Comment #2 from pmachata at gmail dot com ---
On Dec 31, 2016 00:14, "luizluca at gmail dot com" <
sourceware-bugzilla@sourceware.org> wrote:

--- a/libcpu/i386_disasm.c
+++ b/libcpu/i386_disasm.c
@@ -822,6 +822,7 @@ i386_disasm (Ebl *ebl __attribute__((unu
              /* Fallthrough */
            default:
              assert (! "INVALID not handled");
+             str = "";


Or abort() instead? The point is that the assert always fails. Which it
does, unless you compile with -DNDEBUG. So just force it?

Thanks,
Petr

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized

[mjw at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21011

Mark Wielaard <mjw at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjw at redhat dot com

--- Comment #3 from Mark Wielaard <mjw at redhat dot com> ---
If you are just compiling with non-standard build flags then just add
-Wno-error.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=21011

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |mark at klomp dot org
         Resolution|---                         |INVALID

--- Comment #4 from Mark Wielaard <mark at klomp dot org> ---
Looks like if you compile with non-standard flags and -Wno-error this is fine.
Fell free to reopen if you believe this is not the solution.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized

[luizluca at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21011

--- Comment #6 from Luiz Angelo Daros de Luca <luizluca at gmail dot com> ---
Mark,

I know that both might be a compiler bug. However, the cost of solving them are
very low.

Yes, I might be compiling elfutils with non-standard options. However, the
non-standard might be the standard for some distribution like LEDE/OpenWRT.

The alternative for me is not to use -Wno-error but to patch the code (and
maintain the patch) until compiler gets it right. I was just hoping that fixing
this upstream will help any other elfutils users that need to compile with
those non-standard flags on.

I'll reopen only once more this bug. If you think that it should not be "fixed"
upstream, mark it again as resolved and I'll let it go.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized

[luizluca at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21011

--- Comment #5 from Luiz Angelo Daros de Luca <luizluca at gmail dot com> ---
Mark,

I know that both might be a compiler bug. However, the cost of solving them are
very low.

Yes, I might be compiling elfutils with non-standard options. However, the
non-standard might be the standard for some distribution like LEDE/OpenWRT.

The alternative for me is not to use -Wno-error but to patch the code (and
maintain the patch) until compiler gets it right. I was just hoping that fixing
this upstream will help any other elfutils users that need to compile with
those non-standard flags on.

I'll reopen only once more this bug. If you think that it should not be "fixed"
upstream, mark it again as resolved and I'll let it go.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized

[luizluca at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21011

Luiz Angelo Daros de Luca <luizluca at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #7 from Luiz Angelo Daros de Luca <luizluca at gmail dot com> ---
returning to unconfirmed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=21011

--- Comment #8 from Mark Wielaard <mark at klomp dot org> ---
Please post how exactly you are configuring the build, compiler (version) and
flags used.

It would certainly help to have a concrete patch against current git.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized

[luizluca at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21011

--- Comment #9 from Luiz Angelo Daros de Luca <luizluca at gmail dot com> ---

./configure is called as:

AR="i486-openwrt-linux-musl-gcc-ar" AS="i486-openwrt-linux-musl-gcc -c -Os
-pipe -march=pentium4 -fno-caller-saves -fno-plt -fhonour-copts
-Wno-error=unused-but-set-variable -Wno-error=unused-result
-iremap/home/REDETRESC/luizluca/prog-local/lede/trunk/build_dir/target-i386_pentium4_musl/elfutils-0.168:elfutils-0.168
-Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1
-Wl,-z,now -Wl,-z,relro
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libiconv-stub/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libintl-stub/include
-D_GNU_SOURCE" LD=i486-openwrt-linux-musl-ld
NM="i486-openwrt-linux-musl-gcc-nm" CC="i486-openwrt-linux-musl-gcc"
GCC="i486-openwrt-linux-musl-gcc" CXX="i486-openwrt-linux-musl-g++"
RANLIB="i486-openwrt-linux-musl-gcc-ranlib" STRIP=i486-openwrt-linux-musl-strip
OBJCOPY=i486-openwrt-linux-musl-objcopy OBJDUMP=i486-openwrt-linux-musl-objdump
SIZE=i486-openwrt-linux-musl-size CFLAGS="-Os -pipe -march=pentium4
-fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable
-Wno-error=unused-result
-iremap/home/REDETRESC/luizluca/prog-local/lede/trunk/build_dir/target-i386_pentium4_musl/elfutils-0.168:elfutils-0.168
-Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1
-Wl,-z,now -Wl,-z,relro
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libiconv-stub/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libintl-stub/include
-D_GNU_SOURCE " CXXFLAGS="-Os -pipe -march=pentium4 -fno-caller-saves -fno-plt
-fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result
-iremap/home/REDETRESC/luizluca/prog-local/lede/trunk/build_dir/target-i386_pentium4_musl/elfutils-0.168:elfutils-0.168
-Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1
-Wl,-z,now -Wl,-z,relro
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libiconv-stub/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libintl-stub/include
-D_GNU_SOURCE "
CPPFLAGS="-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/toolchain-i386_pentium4_gcc-5.4.0_musl/usr/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/toolchain-i386_pentium4_gcc-5.4.0_musl/include/fortify
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/toolchain-i386_pentium4_gcc-5.4.0_musl/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libiconv-stub/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libintl-stub/include
"
LDFLAGS="-L/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib
-L/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/lib
-L/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/toolchain-i386_pentium4_gcc-5.4.0_musl/usr/lib
-L/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/toolchain-i386_pentium4_gcc-5.4.0_musl/lib
-znow -zrelro
-L/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libiconv-stub/lib
-Wl,-rpath-link=/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libiconv-stub/lib
-L/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libintl-stub/lib
-Wl,-rpath-link=/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libintl-stub/lib
"  LIBS="-largp"  ./configure --target=i486-openwrt-linux
--host=i486-openwrt-linux --build=x86_64-pc-linux-gnu --program-prefix=""
--program-suffix="" --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin
--sbindir=/usr/sbin --libexecdir=/usr/lib --sysconfdir=/etc
--datadir=/usr/share --localstatedir=/var --mandir=/usr/man --infodir=/usr/info
--disable-nls   --without-lzma

My GCC is:

i486-openwrt-linux-musl-gcc --version
i486-openwrt-linux-musl-gcc (LEDE GCC 5.4.0 r3621-357efba9bb) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

This is my gcc call that fails:

i486-openwrt-linux-musl-gcc -D_GNU_SOURCE -DHAVE_CONFIG_H
-DLOCALEDIR='"/usr/share/locale"' -I. -I..  -I. -I. -I../lib -I..
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/toolchain-i386_pentium4_gcc-5.4.0_musl/usr/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/toolchain-i386_pentium4_gcc-5.4.0_musl/include/fortify
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/toolchain-i386_pentium4_gcc-5.4.0_musl/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libiconv-stub/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libintl-stub/include
 -std=gnu99 -Wall -Wshadow -Wformat=2 -Wold-style-definition
-Wstrict-prototypes -Wlogical-op    -Werror -Wunused -Wextra
-Wstack-usage=262144   -Os -pipe -march=pentium4 -fno-caller-saves -fno-plt
-fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result
-iremap/home/REDETRESC/luizluca/prog-local/lede/trunk/build_dir/target-i386_pentium4_musl/elfutils-0.168:elfutils-0.168
-Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1
-Wl,-z,now -Wl,-z,relro
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libiconv-stub/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libintl-stub/include
-D_GNU_SOURCE  -DBAD_FTS=1 -MT elf_getarsym.o -MD -MP -MF
.deps/elf_getarsym.Tpo -c -o elf_getarsym.o elf_getarsym.c

elf_getarsym.c: In function 'elf_getarsym':
elf_getarsym.c:206:11: error: 'n' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
    size_t sz = n * w;

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=21011

--- Comment #10 from Mark Wielaard <mark at klomp dot org> ---
That is a pretty involved way to configure elfutils. You do add various
-Wno-error=unused-but-set-variable -Wno-error=unused-result options. Why not
just add -Wno-error=maybe-uninitialized in that case?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=21011

--- Comment #11 from Mark Wielaard <mark at klomp dot org> ---
So the flag that seem to trigger it is -Os (but only on 32bit systems?).
Proposed the following:

commit 7114c513fbebcca8b76796b7f64b57447ba383e1
Author: Mark Wielaard <mark@klomp.org>
Date:   Wed Apr 19 17:07:46 2017 +0200

    libelf: Initialize n to zero in elf_getarsym.

    When building with gcc -Os it seems we can inline read_number_entries
    but if that function fails then n will not be initialized. GCC seems not
    to realize that in that case n won't be used at all. Explicitly initialize
    n to zero to prevent a spurious error: 'n' may be used uninitialized in
    this function [-Werror=maybe-uninitialized] in that case.

    https://sourceware.org/bugzilla/show_bug.cgi?id=21011

    Signed-off-by: Mark Wielaard <mark@klomp.org>

https://sourceware.org/ml/elfutils-devel/2017-q2/msg00042.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized

[luizluca at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21011

--- Comment #12 from Luiz Angelo Daros de Luca <luizluca at gmail dot com> ---
Great! Thanks!

How about libcpu/i386_disasm.c case?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=21011

--- Comment #13 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Luiz Angelo Daros de Luca from comment #12)
> Great! Thanks!
> 
> How about libcpu/i386_disasm.c case?

Don't use -DNDEBUG. assert is a noreturn function. The asserts in the code are
deliberately there. If they fail something is seriously wrong.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized

[luizluca at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21011

--- Comment #14 from Luiz Angelo Daros de Luca <luizluca at gmail dot com> ---
I do not set -DNDEBUG. All compiler flags are similar in this case. Maybe a gcc
bug?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=21011

--- Comment #15 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Luiz Angelo Daros de Luca from comment #14)
> I do not set -DNDEBUG. All compiler flags are similar in this case. Maybe a
> gcc bug?

Or your alternative glibc headers don't provide enough information about assert
to the compiler?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=21011

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #16 from Mark Wielaard <mark at klomp dot org> ---
commit 7114c513fbebcca8b76796b7f64b57447ba383e1
Author: Mark Wielaard <mark@klomp.org>
Date:   Wed Apr 19 17:07:46 2017 +0200

    libelf: Initialize n to zero in elf_getarsym.

    When building with gcc -Os it seems we can inline read_number_entries
    but if that function fails then n will not be initialized. GCC seems not
    to realize that in that case n won't be used at all. Explicitly initialize
    n to zero to prevent a spurious error: 'n' may be used uninitialized in
    this function [-Werror=maybe-uninitialized] in that case.

    https://sourceware.org/bugzilla/show_bug.cgi?id=21011

    Signed-off-by: Mark Wielaard <mark@klomp.org>

Pushed to master.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized

[luizluca at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21011

--- Comment #17 from Luiz Angelo Daros de Luca <luizluca at gmail dot com> ---
> Or your alternative glibc headers don't provide enough information about
> assert to the compiler?

musl dropped the attribute noreturn, which got reverted sometime after.

http://www.openwall.com/lists/musl/2016/08/30/1

So, after using a recent musl, libcpu/i386_disasm.c is not an issue anymore.

Thanks!

-- 
You are receiving this mail because:
You are on the CC list for the bug.