git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 09/13] parse-options API: don't restrict OPT_SUBCOMMAND() to one *_fn type

From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date
Nov 5, 2022, 22:33 UTC
Message-ID
<221105.86o7tlvxh0.gmgdl@evledraar.gmail.com>
In-Reply-To
<25776063-a672-fc65-bed3-1bc8536ab8b3@web.de>
On Sat, Nov 05 2022, René Scharfe wrote:
Show 20 quoted lines
> Am 05.11.22 um 14:52 schrieb Ævar Arnfjörð Bjarmason:
>>
>> I think that's an "unportable" extension covered in "J.5 Common
>> extensions", specifically "J.5.7 Function pointer casts":
>>
>> 	A pointer to an object or to void may be cast to a pointer to a
>> 	function, allowing data to be invoked as a function
>>
>> Thus, since the standard already establishes that valid "void *" and
>> "intptr_t" pointers can be cast'd back & forth, the J.5.7 bridges the
>> gap between the two saying a function pointer can be converted to
>> either.
>>
>> Now, I may be missing something here, but I was under the impression
>> that "intptr_t" wasn't special in any way here, and that any casting of
>> a function pointer to either it or a "void *" was what was made portable
>> by "J.5.7".
>
> Do you mean "possible" or "workable" instead of "portable" here?  As you
> write above, J.5.7 is an extension, not (fully) portable.
I think my just-sent in the side-thread should clarify this.
Show 142 quoted lines
>> Anyway, like ssize_t and a few other things this is extended upon and
>> made standard by POSIX. I.e. we're basically talking about whether this
>> passes:
>>
>> 	assert(sizeof(void (*)(void)) == sizeof(void*))
>>
>> And per POSIX
>> (https://pubs.opengroup.org/onlinepubs/9699919799/functions/dlsym.html):
>>
>> 	Note that conversion from a void * pointer to a function pointer
>> 	as in:
>>
>> 		fptr = (int (*)(int))dlsym(handle, "my_function");
>>
>> 	is not defined by the ISO C standard. This standard requires
>> 	this conversion to work correctly on conforming implementations.
>
> Conversion from object pointer to function pointer can still work if
> function pointers are wider.
>
>> So I think aside from other concerns this should be safe to use, as
>> real-world data backing that up we've had a intptr_t converted to a
>> function pointer since v2.35.0: 5cb28270a1f (pack-objects: lazily set up
>> "struct rev_info", don't leak, 2022-03-28).
>
> That may not have reached unusual architectures, yet.  Let's replace
> that cast with something boring before someone gets hurt.  Something
> like this?
>
>
> diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
> index 573d0b20b7..9e6f1530c6 100644
> --- a/builtin/pack-objects.c
> +++ b/builtin/pack-objects.c
> @@ -4154,14 +4154,15 @@ struct po_filter_data {
>  	struct rev_info revs;
>  };
>
> -static struct list_objects_filter_options *po_filter_revs_init(void *value)
> +static int list_objects_filter_cb(const struct option *opt,
> +				  const char *arg, int unset)
>  {
> -	struct po_filter_data *data = value;
> +	struct po_filter_data *data = opt->value;
>
>  	repo_init_revisions(the_repository, &data->revs, NULL);
>  	data->have_revs = 1;
>
> -	return &data->revs.filter;
> +	return opt_parse_list_objects_filter(&data->revs.filter, arg, unset);
>  }
>
>  int cmd_pack_objects(int argc, const char **argv, const char *prefix)
> @@ -4265,7 +4266,7 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
>  			      &write_bitmap_index,
>  			      N_("write a bitmap index if possible"),
>  			      WRITE_BITMAP_QUIET, PARSE_OPT_HIDDEN),
> -		OPT_PARSE_LIST_OBJECTS_FILTER_INIT(&pfd, po_filter_revs_init),
> +		OPT_PARSE_LIST_OBJECTS_FILTER_F(&pfd, list_objects_filter_cb),
>  		OPT_CALLBACK_F(0, "missing", NULL, N_("action"),
>  		  N_("handling for missing objects"), PARSE_OPT_NONEG,
>  		  option_parse_missing_action),
> diff --git a/list-objects-filter-options.c b/list-objects-filter-options.c
> index 5339660238..2e560c2fdb 100644
> --- a/list-objects-filter-options.c
> +++ b/list-objects-filter-options.c
> @@ -286,15 +286,9 @@ void parse_list_objects_filter(
>  		die("%s", errbuf.buf);
>  }
>
> -int opt_parse_list_objects_filter(const struct option *opt,
> +int opt_parse_list_objects_filter(struct list_objects_filter_options *filter_options,
>  				  const char *arg, int unset)
>  {
> -	struct list_objects_filter_options *filter_options = opt->value;
> -	opt_lof_init init = (opt_lof_init)opt->defval;
> -
> -	if (init)
> -		filter_options = init(opt->value);
> -
>  	if (unset || !arg)
>  		list_objects_filter_set_no_filter(filter_options);
>  	else
> @@ -302,6 +296,12 @@ int opt_parse_list_objects_filter(const struct option *opt,
>  	return 0;
>  }
>
> +int opt_parse_list_objects_filter_cb(const struct option *opt,
> +				     const char *arg, int unset)
> +{
> +	return opt_parse_list_objects_filter(opt->value, arg, unset);
> +}
> +
>  const char *list_objects_filter_spec(struct list_objects_filter_options *filter)
>  {
>  	if (!filter->filter_spec.len)
> diff --git a/list-objects-filter-options.h b/list-objects-filter-options.h
> index 7eeadab2dd..fc6b4da06d 100644
> --- a/list-objects-filter-options.h
> +++ b/list-objects-filter-options.h
> @@ -107,31 +107,26 @@ void parse_list_objects_filter(
>  	struct list_objects_filter_options *filter_options,
>  	const char *arg);
>
> +int opt_parse_list_objects_filter(struct list_objects_filter_options *filter_options,
> +				  const char *arg, int unset);
> +
>  /**
>   * The opt->value to opt_parse_list_objects_filter() is either a
>   * "struct list_objects_filter_option *" when using
>   * OPT_PARSE_LIST_OBJECTS_FILTER().
>   *
> - * Or, if using no "struct option" field is used by the callback,
> - * except the "defval" which is expected to be an "opt_lof_init"
> - * function, which is called with the "opt->value" and must return a
> - * pointer to the ""struct list_objects_filter_option *" to be used.
> - *
> - * The OPT_PARSE_LIST_OBJECTS_FILTER_INIT() can be used e.g. the
> - * "struct list_objects_filter_option" is embedded in a "struct
> - * rev_info", which the "defval" could be tasked with lazily
> - * initializing. See cmd_pack_objects() for an example.
> + * Or, OPT_PARSE_LIST_OBJECTS_FILTER_F() can be used to specify a
> + * custom callback function that may expect a different type.
>   */
> -int opt_parse_list_objects_filter(const struct option *opt,
> -				  const char *arg, int unset);
> +int opt_parse_list_objects_filter_cb(const struct option *opt,
> +				     const char *arg, int unset);
>  typedef struct list_objects_filter_options *(*opt_lof_init)(void *);
> -#define OPT_PARSE_LIST_OBJECTS_FILTER_INIT(fo, init) \
> +#define OPT_PARSE_LIST_OBJECTS_FILTER_F(fo, fn) \
>  	{ OPTION_CALLBACK, 0, "filter", (fo), N_("args"), \
> -	  N_("object filtering"), 0, opt_parse_list_objects_filter, \
> -	  (intptr_t)(init) }
> +	  N_("object filtering"), 0, (fn) }
>
>  #define OPT_PARSE_LIST_OBJECTS_FILTER(fo) \
> -	OPT_PARSE_LIST_OBJECTS_FILTER_INIT((fo), NULL)
> +	OPT_PARSE_LIST_OBJECTS_FILTER_F((fo), opt_parse_list_objects_filter_cb)
>
>  /*
>   * Translates abbreviated numbers in the filter's filter_spec into their
I think "just leave it, and see if anyone complains".

If you look over config.mak.uname you can see what we're likely to be ported to (and some of that's probably dead). The list of potential targets that:

 1) We know of ports to, or people would plausibly port git to
 2) Are updated so slow that they're on a release that's getting close
    to a year old.

Are small, and it's usually easy to look up their memory model etc. are you concerned about any specific one?

I think if you're worried enough about it to push for the diff above: Can we just hide it behind an "#ifdef", then if we find that nobody's using it, we can consider it safe to use.

I don't think there's any great benefit to the extension in that specific case, but there might be in the future (e.g. this topic would be one small user), so since we already have an unintentional test ballon, why not see if we can keep it safely?

Previous: René ScharfeNext: René Scharfe
Message 93 of 106 in “"git bisect run" strips "--log" from the list of arguments”
  1. Lukáš DoktorNov 4, 2022
  2. Jeff KingNov 4, 2022
  3. Đoàn Trần Công DanhNov 4, 2022
  4. Jeff KingNov 4, 2022
  5. Ævar Arnfjörð BjarmasonNov 4, 2022
  6. Jeff KingNov 4, 2022
  7. Ævar Arnfjörð BjarmasonNov 4, 2022
  8. SZEDER GáborNov 4, 2022
  9. Jeff KingNov 4, 2022
  10. 0/3 Convert git-bisect--helper to OPT_SUBCOMMANDĐoàn Trần Công Danh, Nov 4, 2022
  11. 1/3 bisect--helper: remove unused optionsĐoàn Trần Công Danh, Nov 4, 2022
  12. Jeff KingNov 4, 2022
  13. 2/3 bisect--helper: move all subcommands into their own functionsĐoàn Trần Công Danh, Nov 4, 2022
  14. Jeff KingNov 4, 2022
  15. Ævar Arnfjörð BjarmasonNov 4, 2022
  16. Đoàn Trần Công DanhNov 4, 2022
  17. 3/3 bisect--helper: parse subcommand with OPT_SUBCOMMANDĐoàn Trần Công Danh, Nov 4, 2022
  18. Jeff KingNov 4, 2022
  19. Ævar Arnfjörð BjarmasonNov 4, 2022
  20. Đoàn Trần Công DanhNov 4, 2022
  21. Ævar Arnfjörð BjarmasonNov 4, 2022
  22. 0/3 Convert git-bisect--helper to OPT_SUBCOMMANDĐoàn Trần Công Danh, Nov 5, 2022
  23. 1/3 bisect--helper: remove unused optionsĐoàn Trần Công Danh, Nov 5, 2022
  24. 3/3 bisect--helper: parse subcommand with OPT_SUBCOMMANDĐoàn Trần Công Danh, Nov 5, 2022
  25. 2/3 bisect--helper: move all subcommands into their own functionsĐoàn Trần Công Danh, Nov 5, 2022
  26. Đoàn Trần Công DanhNov 5, 2022
  27. 00/13 Turn git-bisect to be builtinĐoàn Trần Công Danh, Nov 5, 2022
  28. 01/13 bisect tests: test for v2.30.0 "bisect run" regressionsĐoàn Trần Công Danh, Nov 5, 2022
  29. Ævar Arnfjörð BjarmasonNov 7, 2022
  30. Đoàn Trần Công DanhNov 8, 2022
  31. 02/13 bisect: refactor bisect_run() to match CodingGuidelinesĐoàn Trần Công Danh, Nov 5, 2022
  32. 03/13 bisect--helper: pass arg[cv] down to do_bisect_runĐoàn Trần Công Danh, Nov 5, 2022
  33. 04/13 bisect: fix output regressions in v2.30.0Đoàn Trần Công Danh, Nov 5, 2022
  34. 05/13 bisect run: keep some of the post-v2.30.0 outputĐoàn Trần Công Danh, Nov 5, 2022
  35. Ævar Arnfjörð BjarmasonNov 7, 2022
  36. Đoàn Trần Công DanhNov 8, 2022
  37. Ævar Arnfjörð BjarmasonNov 8, 2022
  38. 06/13 bisect--helper: remove unused arguments from do_bisect_runĐoàn Trần Công Danh, Nov 5, 2022
  39. 07/13 bisect--helper: pretend we're real bisect when report errorĐoàn Trần Công Danh, Nov 5, 2022
  40. Ævar Arnfjörð BjarmasonNov 7, 2022
  41. 08/13 bisect test: test exit codes on bad usageĐoàn Trần Công Danh, Nov 5, 2022
  42. 09/13 bisect--helper: emit usage for "git bisect"Đoàn Trần Công Danh, Nov 5, 2022
  43. 10/13 bisect--helper: make `state` optionalĐoàn Trần Công Danh, Nov 5, 2022
  44. 11/13 bisect--helper: remove subcommand stateĐoàn Trần Công Danh, Nov 5, 2022
  45. Ævar Arnfjörð BjarmasonNov 7, 2022
  46. Đoàn Trần Công DanhNov 8, 2022
  47. 12/13 bisect--helper: log: allow arbitrary number of argumentsĐoàn Trần Công Danh, Nov 5, 2022
  48. 13/13 Turn `git bisect` into a full built-inĐoàn Trần Công Danh, Nov 5, 2022
  49. Taylor BlauNov 5, 2022
  50. 0/3 Convert git-bisect--helper to OPT_SUBCOMMANDĐoàn Trần Công Danh, Nov 10, 2022
  51. 1/3 bisect--helper: remove unused optionsĐoàn Trần Công Danh, Nov 10, 2022
  52. Ævar Arnfjörð BjarmasonNov 11, 2022
  53. 2/3 bisect--helper: move all subcommands into their own functionsĐoàn Trần Công Danh, Nov 10, 2022
  54. Ævar Arnfjörð BjarmasonNov 11, 2022
  55. 3/3 bisect--helper: parse subcommand with OPT_SUBCOMMANDĐoàn Trần Công Danh, Nov 10, 2022
  56. 00/11 Turn git-bisect to be builtinĐoàn Trần Công Danh, Nov 10, 2022
  57. 02/11 bisect: refactor bisect_run() to match CodingGuidelinesĐoàn Trần Công Danh, Nov 10, 2022
  58. 01/11 bisect tests: test for v2.30.0 "bisect run" regressionsĐoàn Trần Công Danh, Nov 10, 2022
  59. 03/11 bisect: fix output regressions in v2.30.0Đoàn Trần Công Danh, Nov 10, 2022
  60. 04/11 bisect run: keep some of the post-v2.30.0 outputĐoàn Trần Công Danh, Nov 10, 2022
  61. 05/11 bisect-run: verify_good: account for non-negative exit statusĐoàn Trần Công Danh, Nov 10, 2022
  62. 06/11 bisect--helper: identify as bisect when report errorĐoàn Trần Công Danh, Nov 10, 2022
  63. 07/11 bisect test: test exit codes on bad usageĐoàn Trần Công Danh, Nov 10, 2022
  64. 08/11 bisect--helper: emit usage for "git bisect"Đoàn Trần Công Danh, Nov 10, 2022
  65. 09/11 bisect--helper: handle states directlyĐoàn Trần Công Danh, Nov 10, 2022
  66. 10/11 bisect--helper: log: allow arbitrary number of argumentsĐoàn Trần Công Danh, Nov 10, 2022
  67. Ævar Arnfjörð BjarmasonNov 11, 2022
  68. 11/11 Turn `git bisect` into a full built-inĐoàn Trần Công Danh, Nov 10, 2022
  69. Ævar Arnfjörð BjarmasonNov 11, 2022
  70. Jeff KingNov 11, 2022
  71. Ævar Arnfjörð BjarmasonNov 11, 2022
  72. Taylor BlauNov 11, 2022
  73. Taylor BlauNov 15, 2022
  74. Jeff KingNov 15, 2022
  75. Taylor BlauNov 15, 2022
  76. Ævar Arnfjörð BjarmasonNov 11, 2022
  77. 00/13 bisect: v2.30.0 "run" regressions + make it built-inÆvar Arnfjörð Bjarmason, Nov 4, 2022
  78. 01/13 bisect tests: test for v2.30.0 "bisect run" regressionsÆvar Arnfjörð Bjarmason, Nov 4, 2022
  79. 02/13 bisect: refactor bisect_run() to match CodingGuidelinesÆvar Arnfjörð Bjarmason, Nov 4, 2022
  80. 04/13 bisect run: fix "--log" eating regression in v2.30.0Ævar Arnfjörð Bjarmason, Nov 4, 2022
  81. 03/13 bisect: fix output regressions in v2.30.0Ævar Arnfjörð Bjarmason, Nov 4, 2022
  82. 05/13 bisect run: keep some of the post-v2.30.0 outputÆvar Arnfjörð Bjarmason, Nov 4, 2022
  83. 06/13 bisect test: test exit codes on bad usageÆvar Arnfjörð Bjarmason, Nov 4, 2022
  84. 07/13 bisect--helper: emit usage for "git bisect"Ævar Arnfjörð Bjarmason, Nov 4, 2022
  85. 09/13 parse-options API: don't restrict OPT_SUBCOMMAND() to one *_fn typeÆvar Arnfjörð Bjarmason, Nov 4, 2022
  86. René ScharfeNov 5, 2022
  87. Đoàn Trần Công DanhNov 5, 2022
  88. Phillip WoodNov 5, 2022
  89. Ævar Arnfjörð BjarmasonNov 5, 2022
  90. Phillip WoodNov 5, 2022
  91. Ævar Arnfjörð BjarmasonNov 5, 2022
  92. René ScharfeNov 5, 2022
  93. Ævar Arnfjörð BjarmasonNov 5, 2022
  94. René ScharfeNov 6, 2022
  95. Ævar Arnfjörð BjarmasonNov 6, 2022
  96. René ScharfeNov 12, 2022
  97. Jeff KingNov 12, 2022
  98. Ævar Arnfjörð BjarmasonNov 12, 2022
  99. René ScharfeNov 13, 2022
  100. 08/13 bisect--helper: have all functions take state, argc, argv, prefixÆvar Arnfjörð Bjarmason, Nov 4, 2022
  101. 10/13 bisect--helper: remove dead --bisect-{next-check,autostart} codeÆvar Arnfjörð Bjarmason, Nov 4, 2022
  102. 11/13 bisect--helper: convert to OPT_SUBCOMMAND_CB()Ævar Arnfjörð Bjarmason, Nov 4, 2022
  103. 12/13 bisect--helper: make `state` optionalÆvar Arnfjörð Bjarmason, Nov 4, 2022
  104. 13/13 Turn `git bisect` into a full built-inÆvar Arnfjörð Bjarmason, Nov 4, 2022
  105. Taylor BlauNov 5, 2022
  106. Johannes SchindelinNov 10, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.