diff mbox

powerpc: Fix unitialized variable

Message ID 54889AAC.3060404@linux.vnet.ibm.com
State Rejected
Headers

Commit Message

Adhemerval Zanella Netto Dec. 10, 2014, 7:10 p.m. UTC 
  The 'resolv/res_send.c' build with _STRING_ARCH_unaligned not defined
may utilize the local resplen uninitialized.  This patch sets it to 0.

Tested on powerpc64 and powercp32. Along with the e_lgammal_r patch,
it fixes the powerpc warning build with werror.

--

* resolv/res_send.c (send_vc): Fix unitialized variable.

--

Comments

Joseph Myers Dec. 10, 2014, 9:22 p.m. UTC | #1 
On Wed, 10 Dec 2014, Adhemerval Zanella wrote:

> The 'resolv/res_send.c' build with _STRING_ARCH_unaligned not defined
> may utilize the local resplen uninitialized.  This patch sets it to 0.

Do you have an actual path through the function that can result in it 
being used uninitialized, and where a value of 0 is correct?

My understanding, as described in 
<https://sourceware.org/ml/libc-alpha/2014-11/msg00693.html>, was that 
this is a false positive warning - the variable is never actually used 
uninitialized, but determining that requires considering the values other 
variables can have on the paths leading to resplen being used.  And since 
we don't want to add initializations (to installed code as opposed to 
testcases) that actually require code to be generated simply in order to 
avoid warnings, that may indicate disabling -Wmaybe-uninitialized around 
the code that generates the warning.
Adhemerval Zanella Netto Dec. 10, 2014, 11:42 p.m. UTC | #2 
On 10-12-2014 19:22, Joseph Myers wrote:
> On Wed, 10 Dec 2014, Adhemerval Zanella wrote:
>
>> The 'resolv/res_send.c' build with _STRING_ARCH_unaligned not defined
>> may utilize the local resplen uninitialized.  This patch sets it to 0.
> Do you have an actual path through the function that can result in it 
> being used uninitialized, and where a value of 0 is correct?

I do not, I used as default just to avoid the warning.

>
> My understanding, as described in 
> <https://sourceware.org/ml/libc-alpha/2014-11/msg00693.html>, was that 
> this is a false positive warning - the variable is never actually used 
> uninitialized, but determining that requires considering the values other 
> variables can have on the paths leading to resplen being used.  And since 
> we don't want to add initializations (to installed code as opposed to 
> testcases) that actually require code to be generated simply in order to 
> avoid warnings, that may indicate disabling -Wmaybe-uninitialized around 
> the code that generates the warning.
>
I understand the idea of avoid such warning, I will the compiler directives.
diff mbox

Patch

diff --git a/resolv/res_send.c b/resolv/res_send.c
index af42b8a..c1e0a85 100644
--- a/resolv/res_send.c
+++ b/resolv/res_send.c
@@ -668,7 +668,7 @@  send_vc(res_state statp,
 	// int anssiz = *anssizp;
 	HEADER *anhp = (HEADER *) ans;
 	struct sockaddr_in6 *nsap = EXT(statp).nsaddrs[ns];
-	int truncating, connreset, resplen, n;
+	int truncating, connreset, resplen = 0, n;
 	struct iovec iov[4];
 	u_short len;
 	u_short len2;