[Bug c/42643] "may be used uninitialized" compiled with "-Wall -O"

[steven at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42643

Steven Bosscher <steven at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |mi+gcc at aldan dot
                   |                            |algebra.com
         Resolution|                            |FIXED

--- Comment #3 from Steven Bosscher <steven at gcc dot gnu.org> 2012-12-28 21:27:07 UTC ---
(In reply to comment #2)
> Created attachment 26259 [details]
> Live test case (file from Mozilla's NSS package)
> 
> Even when using gcc-4.6 (more specifically gcc version 4.6.3 20111104
> (prerelease) (FreeBSD Ports Collection)), I still get a bogus warning on the
> attached file, unless the optimization level is at -O3 AND the -fPIC is not
> specified:
> 
> mi@narawntapu:nss/lib/util (1778) gcc46 -Wall -O3 -c nssb64e.i
> mi@narawntapu:nss/lib/util (1779) gcc46 -Wall -O2 -c nssb64e.i
> nssb64e.i: In function 'NSSBase64_EncodeItem_Util':
> nssb64e.i:3239:15: warning: 'out_len' may be used uninitialized in this
> function [-Wuninitialized]
> mi@narawntapu:nss/lib/util (1780) gcc46 -Wall -O3 -fPIC -c nssb64e.i
> nssb64e.i: In function 'NSSBase64_EncodeItem_Util':
> nssb64e.i:3239:15: warning: 'out_len' may be used uninitialized in this
> function [-Wuninitialized]

Why is this warning "bogus" in your opinion? It looks valid to me...

The compiler cannot tell that out_len is initialized. The only place
where out_len can pick up a value, is in the call to PL_Base64EncodeBuffer:

    dummy = PL_Base64EncodeBuffer (inItem->data, inItem->len, 64,
       out_string, max_out_len, &out_len);

The compiler can't look into PL_Base64EncodeBuffer to see if a value will
be assigned to "PRUint32 * output_destlen". The programmer can see that
this will happen, or that otherwise NULL will be returned, but that is a
really hard problem for the compiler.  If you expect it to do that, you
should be looking for a static checker that can do this kind of expensive
analysis. There are GCC plugins that can do it.

FWIW the test case of comment #0 is fixed since GCC 4.6, so closing this
problem report as FIXED.