git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Sixt <j6t@kdbg.org>
Cc: "Jean-Noël Avila" <jn.avila@free.fr>,
	"Phillip Wood" <phillip.wood123@gmail.com>,
	git@vger.kernel.org,
	"Jean-Noël Avila via GitGitGadget" <gitgitgadget@gmail.com>
Subject: Re: [PATCH v2 1/4] i18n: factorize more 'incompatible options' messages
Date: Fri, 28 Jan 2022 15:58:23 -0800	[thread overview]
Message-ID: <xmqqee4rtnts.fsf@gitster.g> (raw)
In-Reply-To: <7f46e276-b669-e8fe-21fd-6b43f5bfb33b@kdbg.org> (Johannes Sixt's message of "Sat, 29 Jan 2022 00:21:51 +0100")

Johannes Sixt <j6t@kdbg.org> writes:

>> +void die_if_incompatible_opt4(int opt1, const char *opt1_name,
>> +							  int opt2, const char *opt2_name,
>> +							  int opt3, const char *opt3_name,
>> +							  int opt4, const char *opt4_name)
>> +{
>> +	int count = 0;
>> +	const char *options[4];
>> +
>> +	if (opt1)
>> +		options[count++] = opt1_name;
>> +	if (opt2)
>> +		options[count++] = opt2_name;
>> +	if (opt3)
>> +		options[count++] = opt3_name;
>> +	if (opt4)
>> +		options[count++] = opt4_name;
>> +	switch (count) {
>> +	case 4:
>> +		die(_("options '%s', '%s', '%s', and '%s' cannot be used together"), opt1_name, opt2_name, opt3_name, opt4_name);
>> +		break;
>> +	case 3:
>> +		die(_("options '%s', '%s', and '%s' cannot be used together"), options[0], options[1], options[2]);
>> +		break;
>> +	case 2:
>> +		die(_("options '%s' and '%s' cannot be used together"), options[0], options[1]);
>> +		break;
>> +	default:
>> +		break;
>> +	}
>> +}
>
> Generally, this is good. I wonder whether we have to expect compiler
> warnings about unreachable break statements after the die() calls.
>
> A bit of code duplication could be avoided if die_if_incompatible_opt3()
> forwarded with an additional pair 0, "" to die_if_incompatible_opt4().

I wondered if a single varargs function

    void die_if_incompatible_optN(const char *name1, int opt1, ...);

that takes a name=NULL terminated sequence of <name, opt> would
work, but

 (1) it would require the caller to always spell out the terminating
     NULL, which may be ugly.

 (2) it would tempt people to programatically generate message for N
     options, which leads to sentence lego, which is the exact
     opposite of what this series wants to achieve.

In any case, I do agree with you that the callers of _opt3()
variants can just pass (0, "unused") in the 4-th slot.  If this were
made varargs, then it only needs to pass NULL at the end, so that
might be an improvement, though.

Also, isn't "if" in the name of the function misleading?  as far as
I can tell, this function is not "check if these options are
compatible and die if some are incompatible with each other", but
the caller is convinced that these options are incompatible before
it decides to call this function and there is no "if" in what this
function can do.

void die_for_incompatible_opts(const char *name1, int opt1, ...)
{
	const char *name[4];
	int count = 0;
        va_list params;

        va_start(params, name1);

        if (opt1)
	        name[count++] = name1;
        while (count < ARRAY_SIZE(name)) {
                const char *n = va_arg(params, const char *);

                if (!n)
			break;
                if (va_arg(params, int))
	                name[count++] = n;
        }
        va_end(params);

        switch (count) {
	default:
		BUG("die-for-incompatible-opts can only take up to %d args",
		    ARRAY_SIZE(name));
	case 4:
		die(_("options '%s', '%s', '%s', and '%s'"
		      " cannot be used together"),
		    name[0], name[1], name[2], name[3]);
		break;
	case 3:
		die(_("options '%s', '%s', and '%s'"
		      " cannot be used together"),
		    name[0], name[1], name[2]);
		break;
	...
	}
}

might be easier to extend when somebody discovers there needs the
"opt5" variant. 

  reply	other threads:[~2022-01-28 23:59 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-22 18:35 [PATCH 0/4] Factorize i18n Jean-Noël Avila via GitGitGadget
2022-01-22 18:35 ` [PATCH 1/4] i18n: factorize more 'incompatible options' messages Jean-Noël Avila via GitGitGadget
2022-01-24  7:14   ` Johannes Sixt
2022-01-24 11:06     ` Phillip Wood
2022-01-25 20:52       ` Jean-Noël AVILA
2022-01-25 21:26         ` Johannes Sixt
2022-01-22 18:35 ` [PATCH 2/4] i18n: factorize "invalid value" messages Jean-Noël Avila via GitGitGadget
2022-01-24 11:09   ` Phillip Wood
2022-01-22 18:35 ` [PATCH 3/4] i18n: remove from i18n strings that do not hold translatable parts Jean-Noël Avila via GitGitGadget
2022-01-22 18:35 ` [PATCH 4/4] i18n: transfer variables into placeholders in command synopsis Jean-Noël Avila via GitGitGadget
2022-01-28 22:23 ` [PATCH v2 0/4] Factorize i18n Jean-Noël Avila via GitGitGadget
2022-01-28 22:24   ` [PATCH v2 1/4] i18n: factorize more 'incompatible options' messages Jean-Noël Avila via GitGitGadget
2022-01-28 23:21     ` Johannes Sixt
2022-01-28 23:58       ` Junio C Hamano [this message]
2022-01-29  8:08         ` Johannes Sixt
2022-01-29 10:41           ` Jean-Noël AVILA
2022-01-29 13:18             ` Johannes Sixt
2022-02-01 21:01     ` Ævar Arnfjörð Bjarmason
2022-01-28 22:24   ` [PATCH v2 2/4] i18n: factorize "invalid value" messages Jean-Noël Avila via GitGitGadget
2022-01-28 22:24   ` [PATCH v2 3/4] i18n: remove from i18n strings that do not hold translatable parts Jean-Noël Avila via GitGitGadget
2022-01-28 22:24   ` [PATCH v2 4/4] i18n: transfer variables into placeholders in command synopsis Jean-Noël Avila via GitGitGadget
2022-01-30 22:01   ` [PATCH v3 0/4] Factorize i18n Jean-Noël Avila via GitGitGadget
2022-01-30 22:01     ` [PATCH v3 1/4] i18n: factorize more 'incompatible options' messages Jean-Noël Avila via GitGitGadget
2022-01-31  7:15       ` Johannes Sixt
2022-01-31 10:56       ` Phillip Wood
2022-01-30 22:01     ` [PATCH v3 2/4] i18n: factorize "invalid value" messages Jean-Noël Avila via GitGitGadget
2022-01-30 22:01     ` [PATCH v3 3/4] i18n: remove from i18n strings that do not hold translatable parts Jean-Noël Avila via GitGitGadget
2022-01-30 22:01     ` [PATCH v3 4/4] i18n: transfer variables into placeholders in command synopsis Jean-Noël Avila via GitGitGadget
2022-01-31 11:00       ` Phillip Wood
2022-01-31 13:36         ` Jean-Noël Avila
2022-01-31  7:15     ` [PATCH v3 0/4] Factorize i18n Johannes Sixt
2022-01-31 22:07     ` [PATCH v4 " Jean-Noël Avila via GitGitGadget
2022-01-31 22:07       ` [PATCH v4 1/4] i18n: factorize more 'incompatible options' messages Jean-Noël Avila via GitGitGadget
2022-01-31 22:41         ` Junio C Hamano
2022-02-01  7:01           ` Johannes Sixt
2022-02-01 17:58             ` Junio C Hamano
2022-02-02 16:05           ` Jean-Noël Avila
2022-02-02 17:29             ` Johannes Sixt
2022-01-31 22:07       ` [PATCH v4 2/4] i18n: factorize "invalid value" messages Jean-Noël Avila via GitGitGadget
2022-01-31 22:07       ` [PATCH v4 3/4] i18n: remove from i18n strings that do not hold translatable parts Jean-Noël Avila via GitGitGadget
2022-01-31 22:07       ` [PATCH v4 4/4] i18n: fix some misformated placeholders in command synopsis Jean-Noël Avila via GitGitGadget

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqee4rtnts.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=j6t@kdbg.org \
    --cc=jn.avila@free.fr \
    --cc=phillip.wood123@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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).