[Privoxy-devel] filters.c: warning: 'xxx' may be used uninitialized in this function [-Wmaybe-uninitialized]

[Fabian Keil]

Lee <ler762 at gmail.com> wrote:

> On 6/1/17, Fabian Keil <fk at fabiankeil.de> wrote:
> > Lee <ler762 at gmail.com> wrote:
> >  
> >> before I go making changes to get rid of compiler warnings, is there
> >> really a problem with variables being uninitialized in filters.c?  I
> >> can't tell :(
> >>
> >> ----------- warnings
> >> i686-w64-mingw32-gcc -c -pipe -O2 -DWINVER=0x501   -mwindows -Wall
> >> -Ipcre  filters.c -o filters.o
> >> filters.c: In function 'match_sockaddr':
> >> filters.c:214:42: warning: 'address_port' may be used uninitialized in
> >> this function [-Wmaybe-uninitialized]
> >>     if (*netmask_port && *network_port != *address_port)
> >>                                           ^  
> >
> > What's the compiler version you're using?  
> 
> $ i686-w64-mingw32-gcc --version
> i686-w64-mingw32-gcc (GCC) 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.

Interesting. I can't reproduce the warnings on ElectroBSD with:

fk at t520 ~/git/privoxy $gcc5 --version
gcc5 (FreeBSD Ports Collection) 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.

but see nothing obvious that would make them a Windows-specific issue.

> > I suspect that it gets confused by the return(-1) blocks in
> > sockaddr_storage_to_ip(). At first glance I believe that
> > they shouldn't be reachable in which case we should probably
> > remove them or make this more obvious.
> >
> > We could start with something like:  
> 
> I don't see any 	[privoxy-commits] messages from sourceforge, so
> you want me to manually make those changes & see what happens?

I haven't committed them to CVS yet but intent to do so tomorrow
after some more testing.

Additional testing on Windows would be appreciated but assuming
the commits don't break anything they seem like improvements
to me even if it turns out that they don't affect the warnings
you're getting.

> > I would prefer to clarify the code first to see if this is sufficient
> > to convince your compiler that the variables are initialised properly.
> >
> > Simply initialising the variables to 0/NULL is likely to result
> > in "dead store" warnings from other compilers.  
> 
> like these?
> i686-w64-mingw32-gcc -c -pipe -O2 -DWINVER=0x501   -mwindows -Wall
> -Ipcre  parsers.c -o parsers.o
> In file included from parsers.c:90:0:
> strptime.h: In function 'strptime_internal':
> strptime.h:277:21: warning: variable 'era' set but not used
> [-Wunused-but-set-variable]
>    struct era_entry *era;
>                      ^
> strptime.h:265:15: warning: variable 'rp_backup' set but not used
> [-Wunused-but-set-variable]
>    const char *rp_backup;
>                ^

Not exactly. Completely unused variables can be simply removed
(or maybe moved into the same ifdef blocks).

clang warns about "dead stores" in cases like:

int bla = 1;
int x;
[ ... no bla reads ... ]
bla = 2;
x = bla; 

The first store is considered dead as the value is never
read but the variable is still being used.

I'm not sure if gcc warns about "dead stores" and
"unused variables" differently but clang does (when
it actually detects them, it didn't detect the
"dead store by memset()" fixed in jcc.c,v 1.455).

> > If the stores weren't actually dead they wouldn't be sufficient to
> > prevent problems anyway.  
> 
> Not that it means a whole lot, but the only problems I've noticed are
> compiler warnings.  I'm not seeing privoxy misbehaving.

Me neither. valgrind hasn't complained about this either.

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.privoxy.org/pipermail/privoxy-devel/attachments/20170601/0886df76/attachment.bin>