From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.2 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6CCEBC433E6 for ; Mon, 1 Feb 2021 23:10:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3CDCD64EAC for ; Mon, 1 Feb 2021 23:10:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229999AbhBAXKM (ORCPT ); Mon, 1 Feb 2021 18:10:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56180 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229593AbhBAXKI (ORCPT ); Mon, 1 Feb 2021 18:10:08 -0500 Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AD601C061573 for ; Mon, 1 Feb 2021 15:09:28 -0800 (PST) Received: by mail-pj1-x1034.google.com with SMTP id my11so685248pjb.1 for ; Mon, 01 Feb 2021 15:09:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GEACQRgbmcNz8U0z7UDtnpZG1N/k6q1juxg0BiyuRck=; b=jcCexse5x5viIjyqRk/y5mlMoRBb37kn+h2DynfRh9CPkpCUZvw57riM5Gi3chT72o CbjVM0TyHXwMcYIJF7XQk7oSx3tqL0DJoW+6ZTL7awz2PCOAzWALcKtKIkscqgdAS+Gc 77zQL6+T9j9Y50TtmJl9WyyTglQbUcODNt/KvAwo9Ankwfj2hcsMdDLtVxBimPo7YNch 4OBb+qFKWQsAS4jSny4JBlmxDnDQsDOJT8zE6iLkurDsvmCMW0kb8R/BDefizWxpO0KE owCJjEWFWzDtQJs+egmj+wBYbKprb/ZVKDFql/vVQCyVTjKpytpTsrvltZRB1Qf0pIV+ kSOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GEACQRgbmcNz8U0z7UDtnpZG1N/k6q1juxg0BiyuRck=; b=iAbqDR15wHNqhaBx7WuPcV+k6AU7jSrz26NMVn9ka9KhDCYUo0SuC9ZNjHiw3lEU/3 1CW0iFQMOzve5I4JT7ht1aiWwMJ6zUSoep6U7J8VNJeMoyo482jkNEJ3F+XeHdFwhMvG 01n6SmQSGYXisGTq6OCsXrZ8ISmLiS8TXv3kbjKqwxyR3Z14moK2tRnwkwEcuKYsUdcN DSQn/RPsjQvHDakyIcszS41ugZ+slD+pYpQOxPuv8cXjCmCIVAMgKjHQ/9Sco+fwxPd0 MJJXab/hPbPon7Tuh0cktevAWKKqxWoR9XfrkCtrBK1rf0/8+NsMWkEWnyqL1iMnOol6 bmCA== X-Gm-Message-State: AOAM530h/gO0UsRBbho/y+sij+qgBHHwPzI9rnALi7R7FWeLCralNisa X8jiEMdvcbO5eBaI6OQ1sHdkoXioCwlF/UKoiqWnnw== X-Google-Smtp-Source: ABdhPJyUeJz/A2+S7M/6sGFuaKli4u2WLQhwpVweNnvF5ZutgJsE2TgbxoIasIyhDAnP65Mb9LCHT0k8gzhoZqWGsvk= X-Received: by 2002:a17:902:728f:b029:e1:70dd:ac67 with SMTP id d15-20020a170902728fb02900e170ddac67mr4444213pll.29.1612220967989; Mon, 01 Feb 2021 15:09:27 -0800 (PST) MIME-Version: 1.0 References: <20210201003125.90257-1-viniciustinti@gmail.com> <20210201124924.GA3284018@infradead.org> In-Reply-To: From: Nick Desaulniers Date: Mon, 1 Feb 2021 15:09:16 -0800 Message-ID: Subject: Re: [PATCH v2] ext4: Enable code path when DX_DEBUG is set To: "Theodore Ts'o" Cc: Vinicius Tinti , Christoph Hellwig , Andreas Dilger , Nathan Chancellor , Ext4 Developers List , LKML , clang-built-linux Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 1, 2021 at 2:48 PM Theodore Ts'o wrote: > > On Mon, Feb 01, 2021 at 07:05:11PM -0300, Vinicius Tinti wrote: > > > > The goal is to try to detect real bugs. In this instance specifically I > > suggested to remove the "if (0) {...}" because it sounded like an > > unused code. > > > > If it is useful it is fine to keep. > > The trick was that it was unused code, but it was pretty obviously > deliberate, which should have implied that at some point, it was > considered useful. :-) > > It was the fact that you were so determined to find a way to suppress > the warning, suggesting multiple tactics, which made me wonder.... why > were you going through so much effort to silence the warning if the > goal was *not* to turn it on unconditionally everywhere? Because a maintainer might say "oh, I meant to turn that back on years ago" or "that should not have been committed!" Hasn't happened yet, doesn't mean it's impossible. Vinicius asked how he can help. I said "go see if any instances of this warning are that case." > > I suspect the much more useful thing to consider is how can we suggest > hueristics to the Clang folks to make the warning more helpful. For > example, Coverity will warn about the following: > > void test_func(unsigned int arg) > { > if (arg < 0) { > printf("Hello, world\n") > } > } Put that code in in godbolt.org (https://godbolt.org/z/E7KK9T) and you'll see that both compilers already warn here on -Wextra (via -Wtautological-unsigned-zero-compare in clang or -Wtype-limits in GCC). clang: warning: result of comparison of unsigned expression < 0 is always false [-Wtautological-unsigned-zero-compare] if (arg < 0) { ~~~ ^ ~ gcc: warning: comparison of unsigned expression in '< 0' is always false [-Wtype-limits] 3 | if (arg < 0) { | ^ > > P.S. If anyone wants to file a feature request bug with the Clang > developers, feel free. :-) -- Thanks, ~Nick Desaulniers