All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Vinicius Tinti <viniciustinti@gmail.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>,
	Christoph Hellwig <hch@infradead.org>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Nathan Chancellor <natechancellor@gmail.com>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	clang-built-linux <clang-built-linux@googlegroups.com>
Subject: Re: [PATCH v2] ext4: Enable code path when DX_DEBUG is set
Date: Mon, 1 Feb 2021 17:48:54 -0500	[thread overview]
Message-ID: <YBiFVgatiz+owBs9@mit.edu> (raw)
In-Reply-To: <CALD9WKx6HREQeTRXuv81v-=DTVuznXG_56YFm2dM1GOG3s4BRQ@mail.gmail.com>

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?

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")
	}
}

This is an example of dead code that is pretty clearly unintended ---
and it's something that "clang -Wall" or "gcc -Wall" doesn't pick up
on, but Coverity does.

So in cases where the code is explicitly doing "if (0)" or "if
(IS_ENABLED(xxx))" where IS_ENABLED resolves down to zero due to
preprocessor magic, arguably, that's not a useful compiler warning
because it almost *certainly* is intentional.  But in the case of an
unsigned int being compared to see if it is less than, or greater than
or equal to 0, that's almost certainly a bug --- and yes, Coverity has
found a real bug (tm) in my code due to that kind of static code
analysis.  So it would actually be quite nice if there was a compiler
warning (either gcc or clang, I don't really care which) which would
reliably call that out without having the maintainer submit the code
to Coverity for analysis.

Cheers,

							- Ted

P.S.  If anyone wants to file a feature request bug with the Clang
developers, feel free.  :-)

  reply	other threads:[~2021-02-01 22:49 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-29 18:58 [PATCH] ext4: Remove unreachable code Vinicius Tinti
2021-01-30  1:35 ` Nathan Chancellor
2021-01-30  6:42 ` Andreas Dilger
2021-02-01  0:31   ` [PATCH v2] ext4: Enable code path when DX_DEBUG is set Vinicius Tinti
2021-02-01  0:48     ` Nathan Chancellor
2021-02-01 12:49     ` Christoph Hellwig
2021-02-01 16:15       ` Vinicius Tinti
2021-02-01 17:13         ` Theodore Ts'o
2021-02-01 18:41           ` Vinicius Tinti
2021-02-01 20:45             ` Andreas Dilger
2021-02-01 21:09             ` Theodore Ts'o
2021-02-01 21:16               ` Nick Desaulniers
2021-02-01 21:38                 ` Theodore Ts'o
2021-02-01 21:41                   ` Nick Desaulniers
2021-02-01 22:05                     ` Vinicius Tinti
2021-02-01 22:48                       ` Theodore Ts'o [this message]
2021-02-01 23:09                         ` Nick Desaulniers
2021-02-02  8:05           ` Christoph Hellwig
2021-02-02 16:28             ` [PATCH v3] " Vinicius Tinti
2021-02-03  5:39               ` Theodore Ts'o
2021-02-03  9:51                 ` Vinicius Tinti
2021-02-01 16:58       ` [PATCH v2] " Theodore Ts'o

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YBiFVgatiz+owBs9@mit.edu \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=clang-built-linux@googlegroups.com \
    --cc=hch@infradead.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=natechancellor@gmail.com \
    --cc=ndesaulniers@google.com \
    --cc=viniciustinti@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.