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

On Mon, Feb 01, 2021 at 03:41:50PM -0300, Vinicius Tinti wrote:
> 
> My goal is to avoid having a dead code. Three options come to mind.
> 
> The first would be to add another #ifdef SOMETHING (suggest a name).
> But this doesn't remove the code and someone could enable it by accident.

I *really* don't see the point of having the compiler whine about
"dead code", so I'm not terribly fond of
-Wunreachable-code-aggressive.  There may be times where depending on
how things are compiled, we *want* the compiler to remove code block,
and it makes the code less ugly than having #ifdef ... #endif breaking
up the code.

If turning that on requires uglifying many places in the kernel code,
maybe the right answer is... don't.

That being said, I have no problem of replacing

	if (0) {
		...
	}

with

#ifdef DX_DEBUG
	...
#endif

In this particular place.

But before we go there, I want to register my extreme skepticsm about
-Wunreachable-code-aggressive.  How much other places where it is
***obvious*** that the maintainer really knew what they are doing, and
it's just the compiler whining about a false positive?

> > However, if there *is* a bug, having an early detection that the
> > representation invariant of the data structure has been violated can
> > be useful in root causing a bug.  This would probably be clearer if
> > the code was pulled out into a separate function with comments
> > explaining that this is a rep invariant check.
> 
> Good idea. I will do that too.

If you want to do that, and do something like

#ifdef DX_DEBUG
static inline htree_rep_invariant_Check(...)
{
	...
}
#else
static inline htree_rep_invariant_check(...) { }
#endif

I'm not going to complain.  That's actually a better way to go, since
there may be other places in the code where a developer might want to
introduce a rep invariant check.  So that's actually improving the
code, as opposed to making a pointless change just to suppress a
compiler warning.

Of course, then someone will try enabling a -W flag which causes the
compiler to whine about empty function bodies....

					- Ted

  parent reply	other threads:[~2021-02-01 21:11 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 [this message]
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
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=YBhuHJgZ3QPqHheV@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.