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.

Reply via email to