Re: [PATCH 2/2] die_for_incompatible_opts(): accept more than four options

Jeff King [off-list ref] writes:

On Thu, Aug 27, 2026 at 07:35:38AM -0700, Junio C Hamano wrote:

quoted

quoted

So that makes sense. Of course the follow-on question is whether any
callers actually want to pass more than 4 options. I don't see any
patches adding new calls.

There isn't.  While I was writing [*], I wondered if the two calls
next to each other for opt3 and opt4 want to be combined to opt7.

OK. I wonder if we're approaching churn here, but I don't have a strong
feeling.

A quiz that I may probably fail if I were asked in a job interview:

- Using die_for_incompatible_opt[234]() functions, find a way for
  any arbitrary N (4 < N) to ensure that no more than two of N
  options are not set at the same time.

  For example, die_for_incompatible_opt5() can be written like so:

    void die_for_incompatible_opt5(int opt1, const char *name1,
				   int opt2, const char *name2,
				   int opt3, const char *name3,
				   int opt4, const char *name4,
				   int opt5, const char *name5)
    {
	die_for_incompatible_opt4(opt1, name1, opt2, name2,
				  opt3, name3, opt4, name4);
	die_for_incompatible_opt4(opt5, name5, opt2, name2,
				  opt3, name3, opt4, name4);
	die_for_incompatible_opt2(opt5, name5, opt1, name1);
    }
	
but can't we do better?  ;-)

Yeah, but then you can't get good compiler support, since I don't think
there is an integer equivalent to LAST_ARG_MUST_BE_NULL.

Ah, I missed that.  It certainly makes sense to flip the order of
these <set, name> pairs.  I suspect that nobody was thinking that
these eventually need to support vararg form when they first added
die_for_incompatible_opt2() and then later extended it to forms that
can support 3 and 4 options; otherwise we would certainly have
chosen the <nameN, setN> order to allow NULL termination.