From patchwork Thu Dec 11 15:29:03 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Adhemerval Zanella X-Patchwork-Id: 420158 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 60AFD14009B for ; Fri, 12 Dec 2014 02:29:22 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; q=dns; s=default; b=jO5P79GEbSvYpBT+IEygL256cEHHCuBbfsicvF4qOVr a+FciRAfuvkE4pyquDQc3vuuf6f/22LWTYZM1QQdgtkmVqQOvbm2fY1k9Q9ELmft R6MUhMdnWWD+VnIVpljldmugiXS5bgaDEDj6xeO0E00N61rDTlvu6nkhdrbxWmGU = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; s=default; bh=HQ76/XTJ22hL6HYAr8pOT2SsvD8=; b=jzkMK8HFXPSTwq7Fu CFpoWISiTkLV5x7jpK5qxGvBeLyaQ98y/XQEU1Y+8xDKCP/TvNct8LV+eJImwRha 1xOaLDvIppcBcK/gBkCM1UMo/C4veV5aIQOVqPB807qAxpzkhFxe2Vfa4onHSDgW szZbbpKvDlx7+BJo0pAtMmHvKE= Received: (qmail 29154 invoked by alias); 11 Dec 2014 15:29:16 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 29141 invoked by uid 89); 11 Dec 2014 15:29:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL, BAYES_00, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e24smtp04.br.ibm.com Message-ID: <5489B83F.6070007@linux.vnet.ibm.com> Date: Thu, 11 Dec 2014 13:29:03 -0200 From: Adhemerval Zanella User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: libc-alpha@sourceware.org Subject: Re: [PATCH] powerpc: Fix unitialized variable References: <54889AAC.3060404@linux.vnet.ibm.com> <5488DA58.9010505@linux.vnet.ibm.com> <54898F5B.2000904@linux.vnet.ibm.com> <5489925D.5010609@linux.vnet.ibm.com> In-Reply-To: X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14121115-0029-0000-0000-0000024604A6 On 11-12-2014 12:40, Joseph Myers wrote: > On Thu, 11 Dec 2014, Adhemerval Zanella wrote: > >> + int truncating, connreset, n; >> + /* There is the following warning on some architectures: >> + 'resplen' may be used uninitialized in this function >> + [-Wmaybe-uninitialized] >> + This is a false positive according to: >> + https://www.sourceware.org/ml/libc-alpha/2014-12/msg00323.html >> + */ >> + DIAG_PUSH_NEEDS_COMMENT; >> + DIAG_IGNORE_NEEDS_COMMENT (4.7, "-Wmaybe-uninitialized"); >> + int resplen; >> + DIAG_POP_NEEDS_COMMENT; > * Do you actually need this here, or only around the use of the variable? Yes, in my testing we need on both places to silent the compiler. > > * An actual analysis of why the variable can't be used uninitialized would > be better than a URL. I.e., if buf2 == NULL then this code won't be > executed; if buf2 != NULL, then first time round the loop recvresp1 and > recvresp2 will be 0 so this code won't be executed but "thisresplenp = > &resplen;" followed by "*thisresplenp = rlen;" will be executed so that > subsequent times round the loop resplen has been initialized. I will replace the ULR pointer with a comment. > > * The version number in DIAG_IGNORE_NEEDS_COMMENT is the most recent GCC > version with which the issue has been observed, not the oldest. Right, I thought I saw it failing by using something different that the compiler used (GCC 4.6 in my tests), but it was a mistake from my part. Changed to 5. > > * A conditional __GNUC_PREREQ (4, 7) is needed around the > DIAG_IGNORE_NEEDS_COMMENT call because 4.6 doesn't have > -Wmaybe-uninitialized (if the warnings appear with 4.6, a #else case to > use -Wuninitialized instead with 4.6 will be needed). > I added the guards. I checked with GCC 4.6 and building with it does not shows the warnings. What about now: --- 2014-12-11 Stefan Liebler Adhemerval Zanella * resolv/res_send.c (send_vc): Disable warning resplen may be used uninitialized. -- diff --git a/resolv/res_send.c b/resolv/res_send.c index af42b8a..9ec951a 100644 --- a/resolv/res_send.c +++ b/resolv/res_send.c @@ -96,6 +96,7 @@ static const char rcsid[] = "$BINDId: res_send.c,v 8.38 2000/03/30 20:16:51 vixi #include #include #include +#include #if PACKETSZ > 65536 #define MAXPACKET PACKETSZ @@ -668,7 +669,24 @@ 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, n; + /* On some architectures compiler might emit a warning indicating + 'resplen' may be used uninitialized. However if buf2 == NULL + then this code won't be executed; if buf2 != NULL, then first + time round the loop recvresp1 and recvresp2 will be 0 so this + code won't be executed but "thisresplenp = &resplen;" followed + by "*thisresplenp = rlen;" will be executed so that subsequent + times round the loop resplen has been initialized. So this is + a false-positive. + */ +#if __GNUC_PREREQ (4, 7) + DIAG_PUSH_NEEDS_COMMENT; + DIAG_IGNORE_NEEDS_COMMENT (5, "-Wmaybe-uninitialized"); +#endif + int resplen; +#if __GNUC_PREREQ (4, 7) + DIAG_POP_NEEDS_COMMENT; +#endif struct iovec iov[4]; u_short len; u_short len2; @@ -787,6 +805,10 @@ send_vc(res_state statp, /* No buffer allocated for the first reply. We can try to use the rest of the user-provided buffer. */ +#if __GNUC_PREREQ (4, 7) + DIAG_PUSH_NEEDS_COMMENT; + DIAG_IGNORE_NEEDS_COMMENT (5, "-Wmaybe-uninitialized"); +#endif #if _STRING_ARCH_unaligned *anssizp2 = orig_anssizp - resplen; *ansp2 = *ansp + resplen; @@ -797,6 +819,9 @@ send_vc(res_state statp, *anssizp2 = orig_anssizp - aligned_resplen; *ansp2 = *ansp + aligned_resplen; #endif +#if __GNUC_PREREQ (4, 7) + DIAG_POP_NEEDS_COMMENT; +#endif } else { /* The first reply did not fit into the user-provided buffer. Maybe the second