[Ltrace-devel] glob.c: In function 'globcomp': error: 'regex' may be used uninitialized in this function [-Werror=maybe-uninitialized]

Sedat Dilek sedat.dilek at gmail.com
Fri Nov 9 07:51:01 UTC 2012


On Thu, Nov 8, 2012 at 9:24 PM, Sedat Dilek <sedat.dilek at gmail.com> wrote:
> On Thu, Nov 8, 2012 at 8:55 PM, Sedat Dilek <sedat.dilek at gmail.com> wrote:
>> On Thu, Nov 8, 2012 at 8:32 PM, Petr Machata <pmachata at redhat.com> wrote:
>>> Sedat Dilek <sedat.dilek at gmail.com> writes:
>>>
>>>> Seen with ltrace-git up to commit
>>>> 4754ea02d067a88e87d4cc67500419f20781de39
>>>> ("4754ea02d067a88e87d4cc67500419f20781de39")
>>>> ...
>>>> libtool: compile:
>>>> /home/wearefam/src/freetz/freetz-git/toolchain/build/mipsel_gcc-4.7.2-RC-20120914_uClibc-0.9.33.2/mipsel-linux-uclibc/bin/mipsel-linux-uclibc-gcc
>>>> -DHAVE_CONFIG_H -I. -I./sysdeps/linux-gnu/mipsel -I./sysdeps/linux-gnu
>>>> -I./sysdeps -I. -DSYSCONFDIR=\"/etc\" -Wall -Wsign-compare
>>>> -Wfloat-equal -Wformat-security -Werror -march=4kc -Os -pipe
>>>> -Wa,--trap -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
>>>> -D_FILE_OFFSET_BITS=64 -MT glob.lo -MD -MP -MF .deps/glob.Tpo -c
>>>> glob.c  -fPIC -DPIC -o .libs/glob.o
>>>> glob.c: In function 'globcomp':
>>>> glob.c:190:9: error: 'regex' may be used uninitialized in this
>>>> function [-Werror=maybe-uninitialized]
>>>> cc1: all warnings being treated as errors
>>>> make[3]: *** [glob.lo] Error 1
>>>> make[3]: Leaving directory
>>>> `/home/wearefam/src/freetz/freetz-git/source/target-mipsel_uClibc-0.9.33.2/ltrace-0.7.0-git'
>>>
>>> Again, this seem spurious.  Regex is initialized in glob_to_regex from
>>> buf, which is itself properly initialized.
>>>
>>> There's not even anything that I can reasonably initialize to.  Should I
>>> use NULL?  Then if it's not overwritten in glob_to_regex, this NULL gets
>>> passed to regcomp, and that SIGSEGVs.  So the full fix should look like:
>>>
>>> --- a/glob.c
>>> +++ b/glob.c
>>> @@ -183,9 +183,9 @@ glob_to_regex(const char *glob, char **retp)
>>>  int
>>>  globcomp(regex_t *preg, const char *glob, int cflags)
>>>  {
>>> -       char *regex;
>>> +       char *regex = NULL;
>>>         int status = glob_to_regex(glob, &regex);
>>> -       if (status != 0)
>>> +       if (status != 0 || regex == NULL)
>>>                 return status;
>>>         status = regcomp(preg, regex, cflags);
>>>         free(regex);
>>>
>>
>> Jupp, that patch compiles fine.
>>
>>> Frankly, that's just silly.  Please update your toolchain.  Let's deal
>>> with this (by filing bugs) if golden GCC complains as well.
>>>
>>
>> Really not sure if updating toolchain will help as it is not only gcc involved.
>> The Freetz project has its own patchsets for diverse toolchain
>> components (binutils, gcc, uClibc, etc.).
>> But I can upgrade to gcc-4.7.2 - if this will be "golden" we will see :-).
>>
>> - Sedat -
>>
>
> $ grep ^diff gcc-4.7.2-RC-20120914-VS-gcc-4.7.2.diff | egrep -v
> 'doc|java|ChangeLog'
> diff -uprN gcc-4.7.2-RC-20120914/gcc/cp/typeck2.c gcc-4.7.2/gcc/cp/typeck2.c
> diff -uprN gcc-4.7.2-RC-20120914/gcc/DATESTAMP gcc-4.7.2/gcc/DATESTAMP
> diff -uprN gcc-4.7.2-RC-20120914/gcc/DEV-PHASE gcc-4.7.2/gcc/DEV-PHASE
> diff -uprN gcc-4.7.2-RC-20120914/gcc/fortran/gfortran.info
> gcc-4.7.2/gcc/fortran/gfortran.info
> diff -uprN gcc-4.7.2-RC-20120914/gcc/gengtype-lex.c gcc-4.7.2/gcc/gengtype-lex.c
> diff -uprN gcc-4.7.2-RC-20120914/gcc/lto/lto.c gcc-4.7.2/gcc/lto/lto.c
> diff -uprN gcc-4.7.2-RC-20120914/gcc/lto-streamer.h gcc-4.7.2/gcc/lto-streamer.h
> diff -uprN gcc-4.7.2-RC-20120914/gcc/po/gcc.pot gcc-4.7.2/gcc/po/gcc.pot
> diff -uprN gcc-4.7.2-RC-20120914/gcc/po/vi.po gcc-4.7.2/gcc/po/vi.po
> diff -uprN gcc-4.7.2-RC-20120914/gcc/testsuite/g++.dg/init/aggr9.C
> gcc-4.7.2/gcc/testsuite/g++.dg/init/aggr9.C
> diff -uprN gcc-4.7.2-RC-20120914/LAST_UPDATED gcc-4.7.2/LAST_UPDATED
> diff -uprN gcc-4.7.2-RC-20120914/libgomp/libgomp.info
> gcc-4.7.2/libgomp/libgomp.info
> diff -uprN gcc-4.7.2-RC-20120914/libitm/libitm.info gcc-4.7.2/libitm/libitm.info
> diff -uprN gcc-4.7.2-RC-20120914/libquadmath/libquadmath.info
> gcc-4.7.2/libquadmath/libquadmath.info
> diff -uprN gcc-4.7.2-RC-20120914/MD5SUMS gcc-4.7.2/MD5SUMS
> diff -uprN gcc-4.7.2-RC-20120914/NEWS gcc-4.7.2/NEWS
>
> On a very quick look this does not really look golden to me.
>

One more thoughts on broken or golden toolchain... gcc's optimization-level.
The Freetz router project uses aggressive "-Os" by default... I could
try more commonly used "-O2".
But... one day or hours before a release a very high burden!

- Sedat -

> - Sedat -
>
>>> Thanks,
>>> PM



More information about the Ltrace-devel mailing list