git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 0/3] Introduce BUG_ON(cond, msg) MACRO

From
Junio C Hamano <gitster@pobox.com>
Date
Nov 23, 2017, 01:38 UTC
Message-ID
<xmqqefopsrk0.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<20171123000839.GL11671@aiede.mtv.corp.google.com>
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.
Previous: Jeff KingNext: Jeff King
Message 17 of 18 in “Introduce BUG_ON(cond, msg) MACRO”
  1. 0/3 Introduce BUG_ON(cond, msg) MACROStefan Beller, Nov 22, 2017
  2. 2/3 git-compat: introduce BUG_ON(condition, fmt, ...) macroStefan Beller, Nov 22, 2017
  3. Jonathan NiederNov 22, 2017
  4. Jeff KingNov 22, 2017
  5. 3/3 contrib/coccinelle: convert all conditional bugs to bug_onStefan Beller, Nov 22, 2017
  6. 1/3 Documentation/CodingGuidelines: explain why assert is badStefan Beller, Nov 22, 2017
  7. Jonathan NiederNov 22, 2017
  8. Stefan BellerNov 22, 2017
  9. Jonathan NiederNov 22, 2017
  10. Jeff KingNov 22, 2017
  11. Jonathan NiederNov 22, 2017
  12. Jeff KingNov 22, 2017
  13. Jonathan NiederNov 22, 2017
  14. Jeff KingNov 22, 2017
  15. Jonathan NiederNov 23, 2017
  16. Jeff KingNov 23, 2017
  17. Junio C HamanoNov 23, 2017
  18. Jeff KingNov 23, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.