git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: "René Scharfe" <l.s.r@web.de>, "Git List" <git@vger.kernel.org>,
	"Jeff King" <peff@peff.net>
Subject: Re: [PATCH 1/2] parse-options: add int value pointer to struct option
Date: Mon, 11 Sep 2023 12:19:17 -0700	[thread overview]
Message-ID: <xmqq7cowv7pm.fsf@gitster.g> (raw)
In-Reply-To: <ZP4NrVeqMtFTLEuf@nand.local> (Taylor Blau's message of "Sun, 10 Sep 2023 14:40:45 -0400")

Taylor Blau <me@ttaylorr.com> writes:

> callback, something like:
>
>     struct option {
>         /* ... */
>         union {
>             void *value;
>             int *value_int;
>             /* etc ... */
>         } u;
>         enum option_type t;
>     };
>
> where option_type has some value corresponding to "void *", another for
> "int *", and so on.

Yup, that does cross my mind, even though I would have used

	union {
		void *void_ptr;
		int *int_ptr;
	} value;

or something without a rather meaningless 'u'.

> Alternatively, perhaps you are thinking that we'd use both the value
> pointer and the value_int pointer to point at potentially different
> values in the same callback. I don't have strong feelings about it, but
> I'd just as soon encourage us to shy away from that approach, since
> assigning a single callback parameter to each function seems more
> organized.

We have seen (with Peff's "-Wunused" work) that there are small
number of cases that it would be handy for a callback to be told the
locations of multiple external variables, but I do not think it
would be a good solution to that problem to have "void *value" and
"int value_int" next to each other and allow them to coexist, as it
would work only when these multiple variables happen to be of the
right types.

  reply	other threads:[~2023-09-11 23:02 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-09 21:10 [PATCH 1/2] parse-options: add int value pointer to struct option René Scharfe
2023-09-09 21:14 ` [PATCH 2/2] parse-options: use and require int pointer for OPT_CMDMODE René Scharfe
2023-09-10 10:18   ` Oswald Buddenhagen
2023-09-11 20:11     ` René Scharfe
2023-09-12  8:40       ` Jeff King
2023-09-16 17:45         ` Junio C Hamano
2023-09-18  9:28           ` René Scharfe
2023-09-18 10:10             ` Oswald Buddenhagen
2023-09-19  7:41               ` René Scharfe
2023-09-21 11:07                 ` [PATCH] am: fix error message in parse_opt_show_current_patch() Oswald Buddenhagen
2023-09-21 19:09                   ` Junio C Hamano
2023-09-21 19:28                     ` Oswald Buddenhagen
2023-09-18 13:33             ` [PATCH 2/2] parse-options: use and require int pointer for OPT_CMDMODE Phillip Wood
2023-09-18 17:11               ` Junio C Hamano
2023-09-18 19:48                 ` Phillip Wood
2023-10-03  8:49                   ` René Scharfe
2023-10-03 17:15                     ` Junio C Hamano
2023-09-19  7:47               ` René Scharfe
2023-09-11 19:12   ` Junio C Hamano
2023-09-11 20:11     ` René Scharfe
2023-09-19  9:40   ` Oswald Buddenhagen
2023-09-20  8:18     ` René Scharfe
2023-09-21 10:40       ` Oswald Buddenhagen
2023-10-03  8:49         ` René Scharfe
2023-10-03  9:38           ` Oswald Buddenhagen
2023-10-03 17:54             ` René Scharfe
2023-10-03 18:24               ` Oswald Buddenhagen
2023-09-10 18:40 ` [PATCH 1/2] parse-options: add int value pointer to struct option Taylor Blau
2023-09-11 19:19   ` Junio C Hamano [this message]
2023-09-11 22:28     ` Oswald Buddenhagen
2023-09-18 11:34       ` Kristoffer Haugsbakk
2023-09-18  9:53     ` René Scharfe
2023-09-18 10:28       ` Oswald Buddenhagen
2023-09-18 16:17       ` Junio C Hamano
2023-09-20 11:34         ` René Scharfe
2023-09-11 20:12   ` René Scharfe

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=xmqq7cowv7pm.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=l.s.r@web.de \
    --cc=me@ttaylorr.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 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 NNTP newsgroup(s).