From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Josh Hagins" <hagins.josh@gmail.com>,
"Git Mailing List" <git@vger.kernel.org>
Subject: Re: [PATCH 1/3] usage.c: add BUG() function
Date: Mon, 15 May 2017 11:28:42 +0900 [thread overview]
Message-ID: <xmqq37c6yht1.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20170513035503.cubqhzcvhifp54yg@sigill.intra.peff.net> (Jeff King's message of "Fri, 12 May 2017 23:55:03 -0400")
Jeff King <peff@peff.net> writes:
> On Fri, May 12, 2017 at 11:28:50PM -0400, Jeff King wrote:
>
>> +static NORETURN void BUG_vfl(const char *file, int line, const char *fmt, va_list params)
>> +{
>> + char prefix[256];
>> +
>> + /* truncation via snprintf is OK here */
>> + if (file)
>> + snprintf(prefix, sizeof(prefix), "BUG: %s:%d: ", file, line);
>> + else
>> + snprintf(prefix, sizeof(prefix), "BUG: ");
>> +
>> + vreportf(prefix, fmt, params);
>> + abort();
>> +}
>
> I used vreportf() here to match die(). But the two things that function
> does are:
>
> 1. Respect error_handle. But after bw/forking-and-threading is merged,
> nobody will ever set error_handle (and I just sent a patch to drop
> it entirely).
>
> 2. Quotes non-printable characters. I don't know how useful this is.
> Most of the assertion messages are pretty vanilla (because anything
> that relies on user input probably should be a regular die, not an
> assertion failure). But a few of them do actually print arbitrary
> strings in a reasonable way (e.g., a BUG() which is handling user
> string which was supposed to be vetted by an earlier function is
> still a reasonable assertion, but it's useful to show the string).
>
> So an alternative would be just:
>
> fprintf(stderr, "BUG: ");
> if (file)
> fprintf(stderr, "%s:%d ", file, line);
> vfprintf(stderr, fmt, params);
> fputc('\n', stderr);
>
> which is perhaps a bit simpler (not much in lines of code, but there's
> no extra buffer to reason about). But given the discussion in (2) above,
> it's probably worth continuing to use vreportf.
Yeah, that does sound sensible. Thanks.
next prev parent reply other threads:[~2017-05-15 2:28 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-12 14:19 [Git 2.13.0] BUG: setup_git_env called without repository Josh Hagins
2017-05-12 14:48 ` Johannes Schindelin
2017-05-15 0:22 ` Josh Hagins
2017-05-12 20:34 ` [PATCH] config: complain about --local outside of a git repo Jeff King
2017-05-12 22:31 ` Ævar Arnfjörð Bjarmason
2017-05-13 2:03 ` Jeff King
2017-05-13 3:24 ` [PATCH 0/3] BUG() and "config --local" outside of repo Jeff King
2017-05-13 3:28 ` [PATCH 1/3] usage.c: add BUG() function Jeff King
2017-05-13 3:55 ` Jeff King
2017-05-15 2:28 ` Junio C Hamano [this message]
2017-05-13 3:29 ` [PATCH 2/3] setup_git_env: convert die("BUG") to BUG() Jeff King
2017-05-13 3:29 ` [PATCH 3/3] config: complain about --local outside of a git repo Jeff King
2018-05-02 9:38 ` [PATCH v2 0/4] Finish the conversion from die("BUG: ...") to BUG() Johannes Schindelin
2018-05-02 9:38 ` [PATCH v2 1/4] test-tool: help verifying BUG() code paths Johannes Schindelin
2018-05-02 15:18 ` Duy Nguyen
2018-05-05 19:30 ` Johannes Schindelin
2018-05-02 9:38 ` [PATCH v2 2/4] run-command: use BUG() to report bugs, not die() Johannes Schindelin
2018-05-07 9:08 ` Jeff King
2018-05-02 9:38 ` [PATCH v2 3/4] Replace all die("BUG: ...") calls by BUG() ones Johannes Schindelin
2018-05-02 9:38 ` [PATCH v2 4/4] Convert remaining die*(BUG) messages Johannes Schindelin
2018-05-07 9:01 ` [PATCH v2 0/4] Finish the conversion from die("BUG: ...") to BUG() Jeff King
2017-05-13 0:04 ` [PATCH] config: complain about --local outside of a git repo Jonathan Nieder
2017-05-13 2:04 ` Jeff King
2017-05-15 0:31 ` Josh Hagins
2017-05-15 3:18 ` 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=xmqq37c6yht1.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=hagins.josh@gmail.com \
--cc=peff@peff.net \
/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.