From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63730 invoked by alias); 3 Mar 2016 17:16:18 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 63180 invoked by uid 89); 3 Mar 2016 17:16:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=Hx-languages-length:1636 X-HELO: mail-ob0-f194.google.com Received: from mail-ob0-f194.google.com (HELO mail-ob0-f194.google.com) (209.85.214.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 03 Mar 2016 17:16:11 +0000 Received: by mail-ob0-f194.google.com with SMTP id hc1so1990947obb.0 for ; Thu, 03 Mar 2016 09:16:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=05ZlQl+xFhpRQA9a54GuBgvtJuAD0+OCo4b3A4Rohkk=; b=AnMha7+1i58rey8RLPqeSRq9ofKqpwpe8qCDxK3EXHKQ8ARiU48XeO+CDXGug06euW 0jSa8sInTWRKFQWE4ISC1SBHkDJ1PqyCNve2PAzSVOgwnQGLYYYabmCMFeHDhJhfcpAa +92F2hft+7mLVPiMKjUsvpIHLDPUibYJ4tUbZEI7Nv5IclBekVQA62thrVBh+DHL4B4B Kx2xCvi7zUgHhy/n2uNQwwcCWGDDbt5+1drQidj49ifMht6Jx9MPQh27wXWyhfIxBlFn OXzvi9XhU/SO7cchBjjLQoGaNR819Mksvbc/bt9+fK6qBpmmBNrmmqA/mzNIg2VIP0Ly 8b6A== X-Gm-Message-State: AD7BkJJ7x+l444mnXMeC/8HrViKEai0nrBu9x9OpgZhVgAAJcFBbt8CD1+sRbvDaZ1QCvqnlsmqs3uzEtudjUg== X-Received: by 10.60.134.171 with SMTP id pl11mr2572870oeb.40.1457025369338; Thu, 03 Mar 2016 09:16:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.29.226 with HTTP; Thu, 3 Mar 2016 09:15:49 -0800 (PST) In-Reply-To: <1457018483-26829-2-git-send-email-dmalcolm@redhat.com> References: <1457018483-26829-1-git-send-email-dmalcolm@redhat.com> <1457018483-26829-2-git-send-email-dmalcolm@redhat.com> From: Patrick Palka Date: Thu, 03 Mar 2016 17:16:00 -0000 Message-ID: Subject: Re: [PATCH 2/2] PR c/68187: fix overzealous -Wmisleading-indentation (comment #1) To: David Malcolm Cc: GCC Patches Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-03/txt/msg00281.txt.bz2 On Thu, Mar 3, 2016 at 10:21 AM, David Malcolm wrote: > Comment #1 of PR c/68187 identified another overzealous warning > from -Wmisleading-indentation, with OpenSSL 1.0.1, on this poorly > indented code: > > 115 if (locked) > 116 i = CRYPTO_add(&e->struct_ref, -1, CRYPTO_LOCK_ENGINE); > 117 else > 118 i = --e->struct_ref; > 119 engine_ref_debug(e, 0, -1) > 120 if (i > 0) > 121 return 1; > > eng_lib.c:120:9: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation] > if (i > 0) > ^~ > eng_lib.c:117:5: note: ...this 'else' clause, but it is not > else > ^~~~ > > Line 120 is poorly indented, but the warning is arguably unjustified. > > Root cause is that "engine_ref_debug" is actually a debugging macro > that was empty in the given configuration, so the code effectively > was: > > 117 else // GUARD > 118 i = --e->struct_ref; // BODY > 119 > 120 if (i > 0) // NEXT > > hence the warning. > > But the code as seen by a human is clearly *not* misleading, and > hence arguably we shouldn't warn for this case. > > The following patch fixes this by ruling that if there is non-whitespace > in a line between the BODY and the NEXT statements, and that this > non-whitespace is effectively an "unindent" or "outdent" (it's not clear > to me which of these terms is better), then to not issue a warning. Cool, this also fixes the false-positives seen in bdwgc, whose coding style suggests indenting things inside an #ifdef as if it were an if(), e.g.: if (a) foo (); # ifndef A bar (); # endif ...