From: "René Scharfe" <l.s.r@web.de>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: git@vger.kernel.org, "Junio C Hamano" <gitster@pobox.com>,
"Jeff King" <peff@peff.net>, "Taylor Blau" <me@ttaylorr.com>,
"Đoàn Trần Công Danh" <congdanhqx@gmail.com>,
"SZEDER Gábor" <szeder.dev@gmail.com>,
"Lukáš Doktor" <ldoktor@redhat.com>,
"Johannes Schindelin" <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH 09/13] parse-options API: don't restrict OPT_SUBCOMMAND() to one *_fn type
Date: Sun, 6 Nov 2022 09:25:35 +0100 [thread overview]
Message-ID: <46ee3f92-943f-10d5-7ec5-c68f1ced87ce@web.de> (raw)
In-Reply-To: <221105.86o7tlvxh0.gmgdl@evledraar.gmail.com>
Am 05.11.22 um 23:33 schrieb Ævar Arnfjörð Bjarmason:
>
> On Sat, Nov 05 2022, René Scharfe wrote:
>
>> 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.
AFAIU you think that J.5.7 plus POSIX make conversions between object
pointers and function pointers portable.
>>> 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.
This means that a compliant implementation could lose bits when going
the other way, i.e. converting a function pointer to an object pointer.
>>> 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?
[snip]
> 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?
Using implementation-defined behavior and requiring extensions when
standard code would work just as well makes no sense to me.
> 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?
You can't certify safety with tests. Undefined behavior may manifest
itself in weird ways and only under certain circumstances. Future
architectures may add new failure modes. It's not like a syntax
extension, to which nonsupporting compilers respond with an error,
i.e. a clear signal.
René
next prev parent reply other threads:[~2022-11-06 8:26 UTC|newest]
Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-04 6:31 "git bisect run" strips "--log" from the list of arguments Lukáš Doktor
2022-11-04 9:45 ` Jeff King
2022-11-04 11:10 ` Đoàn Trần Công Danh
2022-11-04 12:51 ` Jeff King
2022-11-04 11:36 ` Ævar Arnfjörð Bjarmason
2022-11-04 12:45 ` Jeff King
2022-11-04 13:07 ` Ævar Arnfjörð Bjarmason
2022-11-04 12:37 ` SZEDER Gábor
2022-11-04 12:44 ` Jeff King
2022-11-04 11:40 ` [PATCH 0/3] Convert git-bisect--helper to OPT_SUBCOMMAND Đoàn Trần Công Danh
2022-11-04 11:40 ` [PATCH 1/3] bisect--helper: remove unused options Đoàn Trần Công Danh
2022-11-04 12:53 ` Jeff King
2022-11-04 11:40 ` [PATCH 2/3] bisect--helper: move all subcommands into their own functions Đoàn Trần Công Danh
2022-11-04 12:55 ` Jeff King
2022-11-04 13:32 ` Ævar Arnfjörð Bjarmason
2022-11-04 14:03 ` Đoàn Trần Công Danh
2022-11-04 11:40 ` [PATCH 3/3] bisect--helper: parse subcommand with OPT_SUBCOMMAND Đoàn Trần Công Danh
2022-11-04 13:00 ` Jeff King
2022-11-04 13:46 ` Ævar Arnfjörð Bjarmason
2022-11-04 14:07 ` Đoàn Trần Công Danh
2022-11-04 13:55 ` [PATCH 0/3] Convert git-bisect--helper to OPT_SUBCOMMAND Ævar Arnfjörð Bjarmason
2022-11-05 17:03 ` [PATCH v2 " Đoàn Trần Công Danh
2022-11-05 17:03 ` [PATCH v2 1/3] bisect--helper: remove unused options Đoàn Trần Công Danh
2022-11-05 17:03 ` [PATCH v2 2/3] bisect--helper: move all subcommands into their own functions Đoàn Trần Công Danh
2022-11-05 17:13 ` Đoàn Trần Công Danh
2022-11-05 17:03 ` [PATCH v2 3/3] bisect--helper: parse subcommand with OPT_SUBCOMMAND Đoàn Trần Công Danh
2022-11-05 17:07 ` [PATCH 00/13] Turn git-bisect to be builtin Đoàn Trần Công Danh
2022-11-05 17:07 ` [PATCH 01/13] bisect tests: test for v2.30.0 "bisect run" regressions Đoàn Trần Công Danh
2022-11-07 21:31 ` Ævar Arnfjörð Bjarmason
2022-11-08 1:17 ` Đoàn Trần Công Danh
2022-11-05 17:07 ` [PATCH 02/13] bisect: refactor bisect_run() to match CodingGuidelines Đoàn Trần Công Danh
2022-11-05 17:07 ` [PATCH 03/13] bisect--helper: pass arg[cv] down to do_bisect_run Đoàn Trần Công Danh
2022-11-05 17:07 ` [PATCH 04/13] bisect: fix output regressions in v2.30.0 Đoàn Trần Công Danh
2022-11-05 17:07 ` [PATCH 05/13] bisect run: keep some of the post-v2.30.0 output Đoàn Trần Công Danh
2022-11-07 21:40 ` Ævar Arnfjörð Bjarmason
2022-11-08 1:26 ` Đoàn Trần Công Danh
2022-11-08 3:11 ` Ævar Arnfjörð Bjarmason
2022-11-05 17:07 ` [PATCH 06/13] bisect--helper: remove unused arguments from do_bisect_run Đoàn Trần Công Danh
2022-11-05 17:07 ` [PATCH 07/13] bisect--helper: pretend we're real bisect when report error Đoàn Trần Công Danh
2022-11-07 21:29 ` Ævar Arnfjörð Bjarmason
2022-11-05 17:07 ` [PATCH 08/13] bisect test: test exit codes on bad usage Đoàn Trần Công Danh
2022-11-05 17:07 ` [PATCH 09/13] bisect--helper: emit usage for "git bisect" Đoàn Trần Công Danh
2022-11-05 17:07 ` [PATCH 10/13] bisect--helper: make `state` optional Đoàn Trần Công Danh
2022-11-05 17:07 ` [PATCH 11/13] bisect--helper: remove subcommand state Đoàn Trần Công Danh
2022-11-07 21:45 ` Ævar Arnfjörð Bjarmason
2022-11-08 1:27 ` Đoàn Trần Công Danh
2022-11-05 17:07 ` [PATCH 12/13] bisect--helper: log: allow arbitrary number of arguments Đoàn Trần Công Danh
2022-11-05 17:07 ` [PATCH 13/13] Turn `git bisect` into a full built-in Đoàn Trần Công Danh
2022-11-05 23:18 ` [PATCH v2 0/3] Convert git-bisect--helper to OPT_SUBCOMMAND Taylor Blau
2022-11-10 16:36 ` [PATCH v3 " Đoàn Trần Công Danh
2022-11-10 16:36 ` [PATCH v3 1/3] bisect--helper: remove unused options Đoàn Trần Công Danh
2022-11-11 12:42 ` Ævar Arnfjörð Bjarmason
2022-11-10 16:36 ` [PATCH v3 2/3] bisect--helper: move all subcommands into their own functions Đoàn Trần Công Danh
2022-11-11 13:51 ` Ævar Arnfjörð Bjarmason
2022-11-10 16:36 ` [PATCH v3 3/3] bisect--helper: parse subcommand with OPT_SUBCOMMAND Đoàn Trần Công Danh
2022-11-10 16:36 ` [PATCH v2 00/11] Turn git-bisect to be builtin Đoàn Trần Công Danh
2022-11-10 16:36 ` [PATCH v2 01/11] bisect tests: test for v2.30.0 "bisect run" regressions Đoàn Trần Công Danh
2022-11-10 16:36 ` [PATCH v2 02/11] bisect: refactor bisect_run() to match CodingGuidelines Đoàn Trần Công Danh
2022-11-10 16:36 ` [PATCH v2 03/11] bisect: fix output regressions in v2.30.0 Đoàn Trần Công Danh
2022-11-10 16:36 ` [PATCH v2 04/11] bisect run: keep some of the post-v2.30.0 output Đoàn Trần Công Danh
2022-11-10 16:36 ` [PATCH v2 05/11] bisect-run: verify_good: account for non-negative exit status Đoàn Trần Công Danh
2022-11-10 16:36 ` [PATCH v2 06/11] bisect--helper: identify as bisect when report error Đoàn Trần Công Danh
2022-11-10 16:36 ` [PATCH v2 07/11] bisect test: test exit codes on bad usage Đoàn Trần Công Danh
2022-11-10 16:36 ` [PATCH v2 08/11] bisect--helper: emit usage for "git bisect" Đoàn Trần Công Danh
2022-11-10 16:36 ` [PATCH v2 09/11] bisect--helper: handle states directly Đoàn Trần Công Danh
2022-11-10 16:36 ` [PATCH v2 10/11] bisect--helper: log: allow arbitrary number of arguments Đoàn Trần Công Danh
2022-11-11 14:01 ` Ævar Arnfjörð Bjarmason
2022-11-10 16:36 ` [PATCH v2 11/11] Turn `git bisect` into a full built-in Đoàn Trần Công Danh
2022-11-11 13:53 ` Ævar Arnfjörð Bjarmason
2022-11-11 15:37 ` Jeff King
2022-11-11 21:09 ` Ævar Arnfjörð Bjarmason
2022-11-11 22:07 ` [PATCH v2 00/11] Turn git-bisect to be builtin Taylor Blau
2022-11-15 19:18 ` Taylor Blau
2022-11-15 19:36 ` Jeff King
2022-11-15 19:40 ` Taylor Blau
2022-11-11 12:32 ` [PATCH v3 0/3] Convert git-bisect--helper to OPT_SUBCOMMAND Ævar Arnfjörð Bjarmason
2022-11-04 13:22 ` [PATCH 00/13] bisect: v2.30.0 "run" regressions + make it built-in Ævar Arnfjörð Bjarmason
2022-11-04 13:22 ` [PATCH 01/13] bisect tests: test for v2.30.0 "bisect run" regressions Ævar Arnfjörð Bjarmason
2022-11-04 13:22 ` [PATCH 02/13] bisect: refactor bisect_run() to match CodingGuidelines Ævar Arnfjörð Bjarmason
2022-11-04 13:22 ` [PATCH 03/13] bisect: fix output regressions in v2.30.0 Ævar Arnfjörð Bjarmason
2022-11-04 13:22 ` [PATCH 04/13] bisect run: fix "--log" eating regression " Ævar Arnfjörð Bjarmason
2022-11-04 13:22 ` [PATCH 05/13] bisect run: keep some of the post-v2.30.0 output Ævar Arnfjörð Bjarmason
2022-11-04 13:22 ` [PATCH 06/13] bisect test: test exit codes on bad usage Ævar Arnfjörð Bjarmason
2022-11-04 13:22 ` [PATCH 07/13] bisect--helper: emit usage for "git bisect" Ævar Arnfjörð Bjarmason
2022-11-04 13:22 ` [PATCH 08/13] bisect--helper: have all functions take state, argc, argv, prefix Ævar Arnfjörð Bjarmason
2022-11-04 13:22 ` [PATCH 09/13] parse-options API: don't restrict OPT_SUBCOMMAND() to one *_fn type Ævar Arnfjörð Bjarmason
2022-11-05 8:32 ` René Scharfe
2022-11-05 11:34 ` Đoàn Trần Công Danh
2022-11-05 21:32 ` Phillip Wood
2022-11-05 13:52 ` Ævar Arnfjörð Bjarmason
2022-11-05 16:36 ` Phillip Wood
2022-11-05 21:59 ` Ævar Arnfjörð Bjarmason
2022-11-05 17:26 ` René Scharfe
2022-11-05 22:33 ` Ævar Arnfjörð Bjarmason
2022-11-06 8:25 ` René Scharfe [this message]
2022-11-06 13:28 ` Ævar Arnfjörð Bjarmason
2022-11-12 10:42 ` René Scharfe
2022-11-12 16:34 ` Jeff King
2022-11-12 16:55 ` Ævar Arnfjörð Bjarmason
2022-11-13 17:31 ` René Scharfe
2022-11-04 13:22 ` [PATCH 10/13] bisect--helper: remove dead --bisect-{next-check,autostart} code Ævar Arnfjörð Bjarmason
2022-11-04 13:22 ` [PATCH 11/13] bisect--helper: convert to OPT_SUBCOMMAND_CB() Ævar Arnfjörð Bjarmason
2022-11-04 13:22 ` [PATCH 12/13] bisect--helper: make `state` optional Ævar Arnfjörð Bjarmason
2022-11-04 13:22 ` [PATCH 13/13] Turn `git bisect` into a full built-in Ævar Arnfjörð Bjarmason
2022-11-05 0:13 ` [PATCH 00/13] bisect: v2.30.0 "run" regressions + make it built-in Taylor Blau
2022-11-10 12:50 ` Johannes Schindelin
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=46ee3f92-943f-10d5-7ec5-c68f1ced87ce@web.de \
--to=l.s.r@web.de \
--cc=Johannes.Schindelin@gmx.de \
--cc=avarab@gmail.com \
--cc=congdanhqx@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=ldoktor@redhat.com \
--cc=me@ttaylorr.com \
--cc=peff@peff.net \
--cc=szeder.dev@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.
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).