All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
	Taylor Blau <me@ttaylorr.com>,
	Eric Sunshine <sunshine@sunshineco.com>
Subject: Re: [PATCH 1/4] usage.c: add a die_message() routine
Date: Mon, 06 Dec 2021 11:42:42 -0800	[thread overview]
Message-ID: <xmqqee6pfrkd.fsf@gitster.g> (raw)
In-Reply-To: <patch-1.4-5a9ab85fa56-20211206T165221Z-avarab@gmail.com> (=?utf-8?B?IsOGdmFyCUFybmZqw7Zyw7A=?= Bjarmason"'s message of "Mon, 6 Dec 2021 17:55:50 +0100")

Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:

> +int die_message(const char *err, ...) __attribute__((format (printf, 1, 2)));

This probalby makes sense (we'll need to see the caller first).

> +static void die_message_builtin(const char *err, va_list params)
> +{
> +	trace2_cmd_error_va(err, params);
> +	vreportf("fatal: ", err, params);
> +}

I thought the convention was *not* that we name the variant that
takes va_list with _builtin suffix, rather, I thought that the
convention is that ones with the _builtin suffix are meant to be
override-able by other code.

>  /*
>   * We call trace2_cmd_error_va() in the below functions first and
>   * expect it to va_copy 'params' before using it (because an 'ap' can
> @@ -62,10 +68,7 @@ static NORETURN void usage_builtin(const char *err, va_list params)
>   */
>  static NORETURN void die_builtin(const char *err, va_list params)
>  {
> -	trace2_cmd_error_va(err, params);
> -
> -	vreportf("fatal: ", err, params);
> -
> +	die_message_builtin(err, params);
>  	exit(128);
>  }

And by making die() and die_message() both override-able, doesn't it
cause confusion on the caller's end which one should get replaced?
Or with die_message being overridable, we should rewrite the ones
that override die() to instead override die_message()?

It also makes readers wonder why this is not

	exit(die_message(err, params));

which I take it a sign that this new API is overly loose to allow a
simple single thing to be done in multiple ways.  Perhaps as the
series progresses, the picture might improve, but if that is the
case, perhaps the presentation order needs to be rethought.
E.g. start without the _builtin that implies override-ability,
convert the existing code that can benefit from calling die_message(),
and then finally introduce _builtin that is merely an implementation
detail, or something like that, perhaps?

In any case, the first step in this four patch series is not enough
to evaluate if this step makes sense, so let's keep reading.

> @@ -211,6 +214,17 @@ void NORETURN die_errno(const char *fmt, ...)
>  	va_end(params);
>  }
>  
> +#undef die_message
> +int die_message(const char *err, ...)
> +{
> +	va_list params;
> +
> +	va_start(params, err);
> +	die_message_builtin(err, params);
> +	va_end(params);
> +	return 128;
> +}

OK.

Thanks.


>  #undef error_errno
>  int error_errno(const char *fmt, ...)
>  {

  reply	other threads:[~2021-12-06 19:42 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-06 16:55 [PATCH 0/4] usage API: Add and use die_message() Ævar Arnfjörð Bjarmason
2021-12-06 16:55 ` [PATCH 1/4] usage.c: add a die_message() routine Ævar Arnfjörð Bjarmason
2021-12-06 19:42   ` Junio C Hamano [this message]
2021-12-06 19:46     ` Junio C Hamano
2021-12-06 16:55 ` [PATCH 2/4] usage.c API users: use die_message() where appropriate Ævar Arnfjörð Bjarmason
2021-12-06 20:00   ` Junio C Hamano
2021-12-06 16:55 ` [PATCH 3/4] usage.c + gc: add and use a die_message_errno() Ævar Arnfjörð Bjarmason
2021-12-06 21:19   ` Junio C Hamano
2021-12-06 16:55 ` [PATCH 4/4] config API: don't use vreportf(), make it static in usage.c Ævar Arnfjörð Bjarmason
2021-12-06 21:26   ` Junio C Hamano
2021-12-07 18:05     ` Ævar Arnfjörð Bjarmason
2021-12-07 18:26 ` [PATCH v2 0/6] usage API: Add and use die_message() Ævar Arnfjörð Bjarmason
2021-12-07 18:26   ` [PATCH v2 1/6] usage.c: add a die_message() routine Ævar Arnfjörð Bjarmason
2021-12-07 18:26   ` [PATCH v2 2/6] usage.c API users: use die_message() for "fatal :" + exit 128 Ævar Arnfjörð Bjarmason
2021-12-07 18:26   ` [PATCH v2 3/6] usage.c API users: use die_message() for error() " Ævar Arnfjörð Bjarmason
2021-12-07 18:26   ` [PATCH v2 4/6] gc: return from cmd_gc(), don't call exit() Ævar Arnfjörð Bjarmason
2021-12-07 18:26   ` [PATCH v2 5/6] usage.c + gc: add and use a die_message_errno() Ævar Arnfjörð Bjarmason
2021-12-07 18:26   ` [PATCH v2 6/6] config API: use get_error_routine(), not vreportf() Ævar Arnfjörð Bjarmason
2021-12-07 21:24   ` [PATCH v2 0/6] usage API: Add and use die_message() Junio C Hamano
2021-12-22 18:57   ` Jonathan Tan
2021-12-22 19:59     ` Junio C Hamano
2021-12-24 17:01     ` Ævar Arnfjörð Bjarmason

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=xmqqee6pfrkd.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.com \
    --cc=peff@peff.net \
    --cc=sunshine@sunshineco.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.