This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] powerpc: Fix unitialized variable
- From: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: "GNU C. Library" <libc-alpha at sourceware dot org>
- Date: Wed, 10 Dec 2014 21:42:16 -0200
- Subject: Re: [PATCH] powerpc: Fix unitialized variable
- Authentication-results: sourceware.org; auth=none
- References: <54889AAC dot 3060404 at linux dot vnet dot ibm dot com> <alpine dot DEB dot 2 dot 10 dot 1412102119230 dot 26602 at digraph dot polyomino dot org dot uk>
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.