From: Junio C Hamano <gitster@pobox.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Jeff King <peff@peff.net>, Stefan Beller <sbeller@google.com>,
git@vger.kernel.org, git@jeffhostetler.com
Subject: Re: [PATCH 0/3] Introduce BUG_ON(cond, msg) MACRO
Date: Thu, 23 Nov 2017 10:38:07 +0900 [thread overview]
Message-ID: <xmqqefopsrk0.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20171123000839.GL11671@aiede.mtv.corp.google.com> (Jonathan Nieder's message of "Wed, 22 Nov 2017 16:08:39 -0800")
Jonathan Nieder <jrnieder@gmail.com> writes:
> FWIW I think we've done fine at using assert so far. But if I
> understand correctly, the point of this series is to stop having to
> worry about it.
I recalled that there was at least one, and "log -Sassert" piped to
"less" that looks for "/^[ ^I]*assert\(" caught me one recent one.
08414938 ("mailinfo.c: move side-effects outside of assert", 2016-12-19)
Even though I do not personally mind
assert(flags & EXPECTED_BIT);
assert(remaining_doshes == 0);
left as a reminder primarily for coders, we can do just as well do
so with
if (remaining_doshes != 0)
BUG("the gostak did not distim all doshes???");
So I am fine if we want to move to reduce the use of assert()s or
get rid of them. I personally prefer (like Peff, if I am not
mistaken) an explicit use of the usual control structure, as it is
easy to follow. BUG_ON() would become another thing readers need to
get used to, if we were to use it, and my gut feeling is that it may
not be worth it.
A few more random things related to this topic that comes to my
mind:
- If we had a good set of tools to tell us if an expression is free
of side-effects, then assert(<expression>) would be less
problematic---we could mechanically check if an assert() that is
left as a reminder for coders/readers is safe.
- Even if we had such a check, using the check only on new changes
when a patch is accepted is not good enough. An assert(distim())
may have been safe back when it was added because distim() used
to be free of side-effects, but a later update to it may add side
effects to it.
- The issue that is caused by "this function used to be pure but
lately it gained side-effects" is not limited to assert(). Using
it in "if (condition) BUG(...)" or "BUG_ON(condition,...)" will
not sidestep the fact that such a change will alter behaviour of
callers of the function. It's just that assert(condition) is
conditionally compiled, which makes the issue a worse one.
next prev parent reply other threads:[~2017-11-23 1:38 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-22 22:38 [PATCH 0/3] Introduce BUG_ON(cond, msg) MACRO Stefan Beller
2017-11-22 22:38 ` [PATCH 1/3] Documentation/CodingGuidelines: explain why assert is bad Stefan Beller
2017-11-22 22:59 ` Jonathan Nieder
2017-11-22 23:08 ` Stefan Beller
2017-11-22 23:54 ` Jonathan Nieder
2017-11-22 22:38 ` [PATCH 2/3] git-compat: introduce BUG_ON(condition, fmt, ...) macro Stefan Beller
2017-11-22 23:02 ` Jonathan Nieder
2017-11-22 23:37 ` Jeff King
2017-11-22 22:38 ` [PATCH 3/3] contrib/coccinelle: convert all conditional bugs to bug_on Stefan Beller
2017-11-22 23:24 ` [PATCH 0/3] Introduce BUG_ON(cond, msg) MACRO Jeff King
2017-11-22 23:28 ` Jonathan Nieder
2017-11-22 23:39 ` Jeff King
2017-11-22 23:45 ` Jonathan Nieder
2017-11-22 23:58 ` Jeff King
2017-11-23 0:08 ` Jonathan Nieder
2017-11-23 0:10 ` Jeff King
2017-11-23 1:38 ` Junio C Hamano [this message]
2017-11-23 5:00 ` Jeff King
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=xmqqefopsrk0.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@jeffhostetler.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=peff@peff.net \
--cc=sbeller@google.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.